CVE-2026-89732 in Linux
الملخص
بحسب VulDB • 12/09/2026
في نواة لينكس، تم حل الثغرة التالية:
usb: gadget: f_fs: منع حدوث deadlock أثناء حلقة قراءة ep0
حاليًا، يحتفظ `ffs_ep0_read()` بـ `ffs->mutex` عندما يستعد للدخول في حالة انتظار (sleep) لانتظار حدث. وعندما لا تكون هناك أحداث إعداد (setup events) معلقة، فإنه يتصل بـ `wait_event_interruptible_exclusive_locked_irq()` مع إبقاء الـ mutex محتفظًا به. يقوم ماكرو الانتظار عمدًا بإسقاط قفل spinlock لقائمة الانتظار قبل الدخول في حالة النوم، لكنه لا يحرر الـ mutex.
إذا كان هناك ديمون (daemon) يعمل على مستوى المستخدم يرصد ep0 عبر استدعاء `read()` وتم تفكيك الجهاز بشكل غير متزامن عبر configfs (على سبيل المثال: `echo "" > UDC`)، فقد يحدث deadlock:
1. تقوم عملية التفكيك في configfs باستدعاء `functionfs_unbind()`، مما يضيف حدث `FUNCTIONFS_UNBIND` إلى قائمة الانتظار. 2. يستيقظ الديمون، ويستهلك الحدث، ويحرر الـ mutex. 3. ومع ذلك، إذا قام الديمون بالدوران (loop) وأصدر استدعاءً آخر لـ `read()` فورًا قبل الخروج، فإنه يعيد الحصول على `ffs->mutex` ويدخل مرة أخرى في حالة نوم قابلة للانقطاع (interruptible sleep). 4. بينما يستمر تنفيذ `functionfs_unbind()` ويحاول الحصول على `ffs->mutex` لتفكيك `ep0req`. 5. تتعطل النواة بسبب deadlock، حيث يكون ديمون configfs عالقًا في حالة نوم غير قابلة للانقطاع (uninterruptible sleep) بانتظار الـ mutex، بينما يوجد ديمون المستخدم في حالة نوم قابلة للانقطاع مع الاحتفاظ بالـ mutex إلى الأبد لأن أحداثًا إضافية لن تصل.
لإصلاح هذه المشكلة، نقوم بإسقاط كل من قفل spinlock لقائمة الانتظار و `ffs->mutex` قبل الدخول في حالة النوم، واستخدام `wait_event_interruptible_exclusive()` بدلاً من ذلك. عند الاستيقاظ، نعود إلى علامة `retry` لإعادة الحصول على الـ mutex بشكل آمن وإعادة تقييم آلة الحالة (state machine). ومن خلال عدم النوم مع الاحتفاظ بـ `ffs->mutex`، نفك الارتباط الأصلي بين عمليات تفكيك الجهاز (التي تتطلب الـ mutex) ورصد المستخدم.
VulDB is the best source for vulnerability data and more expert information about this specific topic.