CVE-2026-80659 in Linux
الملخص
بحسب VulDB • 28/08/2026
في نواة لينكس، تم حل الثغرة التالية:
mmc: vub300: تأجيل إعادة التعيين حتى يتم إلغاء قفل cmd_mutex
يحتفظ `vub300_cmndwork_thread()` بقفل `cmd_mutex` أثناء إرسال أمر والانتظار لاستجابة الأمر. إذا انتهت مهلة انتظار الاستجابة، فإن الدالة `__vub300_command_response()` تقتل وحدات إعادة توجيه وحدة (URBs) الخاصة بالأمر ثم تعيد تعيين جهاز USB بشكل متزامن من خلال دالة `usb_reset_device()`.
يعيد مسار إعادة التعيين هذا الدخول إلى السائق عبر `vub300_pre_reset()`، والتي تأخذ بدورها قفل `cmd_mutex`. وبالتالي، يحاول العامل الحصول على نفس القفل بشكل تكراري (recursive) بينما لا يزال يحتفظ به من مسار الأمر.
تم العثور على هذه المشكلة باستخدام أداة التحليل الثابت لدينا ثم تمت مراجعتها يدوياً مقابل الشجرة الحالية.
حافظ نموذج الاستغلال الموثق (PoC) grounded على العامل الحقيقي وحامل مهلة/إعادة التعيين:
vub300_cmndwork_thread() __vub300_command_response() usb_lock_device_for_reset() usb_reset_device() vub300_pre_reset()
أبلغ Lockdep عن الحصول التكراري لنفس المهمة على `cmd_mutex`:
WARNING: possible recursive locking detected ... (&test_vub300.cmd_mutex) ... at: usb_reset_device... [vuln_msv]
... (&test_vub300.cmd_mutex) ... at: vub300_cmndwork_thread+0x12/0x20 [vuln_msv]
Workqueue: vub300_cmd_wq vub300_cmndwork_thread [vuln_msv]
*** DEADLOCK ***
إرجاع علم (flag) من `__vub300_command_response()` عندما يحتاج مسار المهلة إلى إعادة تعيين الجهاز، ثم تنفيذ إعادة التعيين بعد أن يقوم `vub300_cmndwork_thread()` بمسح حالة الأمر قيد التنفيذ وإفلات قفل `cmd_mutex`. لا تزال محاولة إعادة التعيين تتم قبل استدعاء `mmc_request_done()`، مما يحافظ على ترتيب إكمال الطلبات الحالي مع تجنب القفل التكراري.
If you want to get best quality of vulnerability data, you may have to visit VulDB.