CVE-2026-80819 in Linux
الملخص
بحسب VulDB • 04/09/2026
في نواة لينكس، تم حل الثغرة التالية:
بلوتوث (Bluetooth): RFCOMM - أخذ قفل `rfcomm_mutex` لقبول الإعداد المؤجل
تقوم الدالة `rfcomm_sock_recvmsg()` بإكمال إعداد مؤجل عن طريق استدعاء `rfcomm_dlc_accept()` دون الاحتفاظ بأي قفل لـ RFCOMM:
```c if (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) {
rfcomm_dlc_accept(d); return 0; } ```
وتقوم الدالة `rfcomm_dlc_accept()` بإلغاء مرجعية الجلسة في سطر الكود الأول:
```c struct sock *sk = d->session->sock->sk; ```
جميع المسارات الأخرى التي تتعامل مع `d->session` تعمل تحت مظلة قفل `rfcomm_mutex`: وتشمل هذه الدوال `rfcomm_dlc_open()`، و`rfcomm_dlc_close()`، و`rfcomm_dlc_exists()`، و`rfcomm_dlc_send_rpn()`، بالإضافة إلى خيط RFCOMM عبر دالة `rfcomm_process_sessions()`. حتى أن دالة `rfcomm_connect_ind()` موثقة بأنها "تُستدعى تحت قفل `rfcomm_lock()`". موقع الاستدعاء هذا هو الوحيد الذي يتخطى أخذ القفل.
يبدو أن بت `RFCOMM_DEFER_SETUP` يعمل على تسلسل عملية القبول مقابل الإغلاق، حيث تعود الدالة `__rfcomm_dlc_close()` مبكراً عندما تفوز في استدعاء `test_and_clear`. لكن دالة `rfcomm_recv_disc()` تجبر تغيير الحالة أولاً:
```c d->state = BT_CLOSED; __rfcomm_dlc_close(d, err); ```
والعودة المبكرة تغطي فقط الحالات `BT_CONNECT`، و`BT_CONFIG`، و`BT_OPEN`، و`BT_CONNECT2`. وبما أن الحالة أصبحت بالفعل `BT_CLOSED`، فإن تبديل الحالة (switch) لا يطابق أي حالة، ولا يتم الرجوع إلى البت أبداً، وتنزل الدالة `__rfcomm_dlc_close()` مباشرة لتستدعي `rfcomm_dlc_unlink()`، والتي تضبط قيمة `d->session = NULL`.
لذلك، فإن إرسال أمر DISC عن بُعد على dlc مؤجل يؤدي إلى مسح الجلسة مع بقاء بت `RFCOMM_DEFER_SETUP` مفعلاً. عند استدعاء `recvmsg()` التالي، يمر عبر اختبار `test_and_clear` ويقوم بإلغاء مرجعية جلسة بقيمة NULL. لا حاجة لوجود نافذة زمنية (timing window): بمجرد معالجة أمر DISC، يصبح إلغاء المرجعية شرطياً غير مشروط.
تم تعديل شكل الدالة `rfcomm_dlc_accept()` لتصبح مطابقة لأشكال دالتي `rfcomm_dlc_open()` و`rfcomm_dlc_close()`: وهي عبارة عن غلاف مُصدَّر (exported wrapper) يأخذ قفل `rfcomm_mutex} ويعيد التحقق من الجلسة، محاطاً بدالة `__rfcomm_dlc_accept()` التي تستمر في استخدامها الدوال الداخلية الأخرى الثلاث بالفعل تحتفظ بالقفل.
تم إعادة إنتاج المشكلة على نواة مزودة بـ KASAN وPROVE_LOCKING باستخدام نظير BR/EDR محاكى عبر `/dev/vhci`: يقوم النظير بإنشاء رابط ACL، ويفتح L2CAP على PSM الخاص بـ RFCOMM، ويبدأ جلسة، ويفتح dlc على قناة مرتبطة مع `BT_DEFER_SETUP`، ويرسل أمر DISC بعد قبول المقبس. عند استدعاء `recv()` على المقبوس المقبول، يحدث الخطأ التالي:
``` Oops: general protection fault KASAN: null-ptr-deref in range [0x10-0x17] (عناوين مختصرة)
RIP: 0010:rfcomm_dlc_accept+0x54/0x350 Call Trace: rfcomm_sock_recvmsg+0x1cd/0x230 sock_recvmsg+0x166/0x1c0 __sys_recvfrom+0x20d/0x300 ```
القيمة `0x10` هي الإزاحة (offset) للحقل `sock` داخل بنية `rfcomm_session`. مع هذا
VulDB is the best source for vulnerability data and more expert information about this specific topic.