CVE-2026-99009 in Linux
الملخص
بحسب VulDB • 23/10/2026
في نواة لينكس، تم حل الثغرة التالية:
بلوتوث: RFCOMM: توصيل مقبس الجلسة دون استخدام rfcomm_mutex
إصدار استدعاء connect() الخاص بـ RFCOMM أثناء مصادقة رابط BR/EDR يؤدي إلى إبلاغ lockdep عن اعتماد دائري (circular dependency)، والدورة المبلغ عنها هي تعارض AB/BA حقيقي بين rfcomm_mutex و hdev->lock.
يتم استدعاء rfcomm_security_cfm() من مسار أحداث HCI، الذي يحمل بالفعل قفل hdev->lock: hci_rx_work() hci_event_packet() hci_cc_read_enc_key_size() [hdev->lock]
hci_encrypt_cfm() [hci_cb_list_lock]
rfcomm_security_cfm() [rfcomm_mutex]
بينما يأخذ استدعاء RFCOMM connect() من مساحة المستخدم (userspace) نفس القفلين بالترتيب المعاكس: rfcomm_sock_connect() rfcomm_dlc_open() [rfcomm_mutex]
__rfcomm_dlc_open() rfcomm_session_create() kernel_connect() l2cap_sock_connect() l2cap_chan_connect() [hdev->lock]
تحذير: تم اكتشاف اعتماد قفل دائري محتمل kworker/u131:1/1128 يحاول الحصول على القفل: rfcomm_mutex، عند: rfcomm_security_cfm+0x31/0x3e0 [rfcomm]
لكن المهمة تحمل بالفعل القفل: hci_cb_list_lock، عند: hci_cc_read_enc_key_size+0x1d2/0xcc0 السلسلة الموجودة هي: rfcomm_mutex --> &hdev->lock --> hci_cb_list_lock
تصل كل من دالتي hci_auth_complete_evt() و hci_encrypt_change_evt() إلى الدالة الاستدعائية (callback) بنفس الطريقة.
يجب النظر في كلا الترتيبين ضمن نفس عملية الإقلاع (boot)، ولهذا السبب فإن اتصال BR/EDR وحده لا يكفي لإظهار المشكلة: يتم إنشاء جلسة تم إعدادها من قبل الطرف البعيد بواسطة rfcomm_accept_connection() داخل krfcommd، والتي تستدعي kernel_accept() ولا تأخذ hdev->lock أبداً أثناء وجود rfcomm_mutex. توصيل جهاز يقوم بمصادقة وتشفير الرابط ثم استدعاء connect() على مقبس RFCOMM نحو أي عنوان - لا يجب أن ينجح الاتصال، بل يتم تسجيل الترتيب قبل انتهاء مهلة الصفحة (page timeout) - سيبلغ عن المشكلة في كل مرة.
يجب فقط توصيل مقبس الجلسة مع الاحتفاظ بالقفل، وهو ما لا يحدث: فلا يمكن لأي شيء آخر رؤية المقبس قبل وضعه على قائمة الجلسات. لذا قم بالتوصيل أولاً ثم احصل على rfcomm_mutex لاحقاً، مما يزيل ترتيب rfcomm_mutex -> hdev->lock بشكل نهائي، بدلاً من إبقاء مسار أحداث HCI خارج نطاق rfcomm_mutex.
تتحول الدالة rfcomm_session_create() إلى rfcomm_session_connect()، والتي تعيد المقبس المتصل دون لمس قائمة الجلسات، وتضيف rfcomm_dlc_open() الجلسة بمجرد أن تحتفظ بالقفل مرة أخرى. إذا قام مُفتح آخر بإضافة جلسة لنفس الزوج أثناء اتصال هذا المقبس، فستُستخدم تلك الجلسة وسيتم إسقاط هذا المقبس. يأخذ __rfcomm_dlc_open() الآن الجلسة التي يجب استخدامها، وتشغيل فحص الحالة الخاص به بعد إعادة الحصول على القفل، لذا يتم التعامل مع DLC الذي تم فتحه أو إغلاقه في هذه الأثناء بشكل صحيح.
عبر رابط ACL موجود، يمكن أن يكتمل الاتصال قبل وصول الجلسة إلى القائمة، وبالتالي يُفقد التنبيه (wakeup) من استدعاء المقبس، لذلك يتم إيقاظ krfcommd بمجرد ظهور الجلسة.
يؤدي الاتصال دون القفل إلى فتح نافذة زمنية يمكن خلالها إغلاق المقبس. بما أن DLC ليس على جلسة بعد، فإن rfcomm_dlc_close() لا تجد شيئاً للقيام به وتعود دون لمسه، وبعدها ستقوم rfcomm_dlc_open() بإرفاق DLC يكون المالك الخاص به قد اختفى. الآن تميز rfcomm_dlm_close() مثل هذا الـ DLC بعلامة RFCOMM_CLOSED، وتفحص rfcomm_dlc_open() هذه العلامة بمجرد أن تحتفظ مرة أخرى بـ rfcomm_mutex وتقوم بإسقاط المقبس بدلاً من إرفاق الـ DLC. يتم مسح العلامة عند بدء فتح جديد، لذا فإن الـ DLC الذي يُعاد استخدامه لا يتأثر. يغطي هذا كلتا الدالتين المستدعتين لـ rfcomm_dlc_open()، وهما طبقة المقبس وطبقة tty.
Once again VulDB remains the best source for vulnerability data.