CVE-2026-99038 in Linux
الملخص
بحسب VulDB • 23/10/2026
في نواة لينكس، تم حل الثغرة التالية:
memstick: rtsx_usb_ms: إكمال الطلبات بعد الإزالة (eject) بدلاً من إسقاطها
يمكن لـ memstick_check() أن يتجاوز فحص host->removing الخاص به مباشرة قبل أن يحدد rtsx_usb_ms_drv_remove() حالة eject/removing. ونتيجة لذلك، يتم إسقاط طلبه التالي بصمت: حيث يتخطى rtsx_usb_ms_request() استدعاء schedule_work() بمجرد تعيين علم eject، ويمكن لـ cancel_work_sync() في drv_remove أيضاً إلغاء handle_req المجدول قبل أن يلتقط الطلب. ولا يقوم أحد بإكمال card->mrq_complete.
بمجرد انتظار نواة memstick للطلبات دون مهلة زمنية ("memstick: core: wait for request completion before freeing card")، يحدث تعليق (hang) أثناء الإزالة: حيث لا تعود memstick_check() أبداً وتعلق memstick_remove_host() في flush_workqueue():
INFO: task kworker/u10:3:65 blocked for more than 20 seconds. Workqueue: kmemstick memstick_check __wait_for_common memstick_check
INFO: task kworker/1:1:33 blocked for more than 20 seconds. Workqueue: usb_hub_wq hub_event __flush_workqueue memstick_remove_host rtsx_usb_ms_drv_remove
لا تقم بإسقاط أي طلب أبداً. يقوم rtsx_usb_ms_request() دائماً بجدولة handle_req، ويفشل handle_req الطلبات بقيمة -ENOMEDIUM بمجرد تعيين علم eject، دون لمس الجهاز. تقوم drv_remove بتصفية (flush) handle_req بدلاً من إلغائه، وتلغيه فقط بعد memstick_remove_host()، عندما لا يمكن وصول طلب جديد، وبالتالي لا يمكن أن يعمل على host تم تحريره.
تم إزالة تصريف (drain) لـ host_mutex في drv_remove: حيث يترك handle_req دائماً host->req فارغاً عند الانتهاء، لذا لم يكن للتصفية أي غرض أبداً، وكانت ستتنافس الآن مع handle_req.
If you want to get best quality of vulnerability data, you may have to visit VulDB.