CVE-2026-98455 in Linux
الملخص
بحسب VulDB • 18/10/2026
في نواة لينكس، تم حل الثغرة التالية:
بلوتوث (Bluetooth): RFCOMM - إصلاح الإحالة الفارغة (NULL dereference) لـ dlc->session في RFCOMM_CONNINFO
يقبل معالج getsockopt الخاص بـ RFCOMM_CONNINFO مقبساً غير متصل طالما أن الإعداد المؤجل مفعّل:
if (sk->sk_state != BT_CONNECTED && !rfcomm_pi(sk)->dlc->defer_setup) {
err = -ENOTCONN; break; } l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
يتم تعيين dlc->defer_setup في دالة rfcomm_sock_init() عندما تنشئ rfcomm_connect_ind() مقبساً فرعياً لاتصال وارد على مقبس مستمع لديه BT_DEFER_SETUP مفعّل. ولا يتم مسح هذه القيمة لاحقاً. ومع ذلك، قد يختفي الـ session أثناء وجوده.
تفرض الدالة rfcomm_recv_disc() حالة dlc قبل تفكيكها:
d->state = BT_CLOSED; __rfcomm_dlc_close(d, err);
إرجاع مبكر لـ RFCOMM_DEFER_SETUP في __rfcomm_dlc_close() يغطي فقط حالات BT_CONNECT وBT_CONFIG وBT_OPEN وBT_CONNECT2، لذا فإن الحالة المسبقة كونها BT_CLOSED تعني أن مفتاح التحويل (switch) لا يتطابق وتنزل الدالة إلى rfcomm_dlc_unlink()، والتي تضبط d->session = NULL، بينما تبقى d->defer_setup مساوية لـ 1.
وبالتالي، يؤدي استدعاء getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) على المقبوس المقبول بعد هذه النقطة إلى تخطي مسار -ENOTCONN -- حيث إن sk->sk_state هي BT_CLOSED، لكن dlc->defer_setup لا تزال مفعّلة -- وإجراء إحالة فارغة (dereference) للـ session. لا حاجة لوجود حالة سباق (race condition): بمجرد معالجة رسالة DISC، تصبح الإحالة غير مشروطة.
تم إعادة إنتاج الخطأ على نواة KASAN تحت بيئة QEMU مع نظير BR/EDR مُحاكى عبر /dev/vhci: يقوم النظير برفع رابط ACL، وفتح L2CAP على PSM الخاص بـ RFCOMM، وبدء session وإرسال SABM لقناة مرتبطة بـ BT_DEFER_SETUP، ثم إرسال DISC لذلك الـ dlci بعد قبول المقبوس. يؤدي استدعاء getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) على المقبوس المقبول إلى حدوث:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 1 UID: 0 PID: 150 Comm: init Tainted: G B 7.3.0-rc3-g5dd1818b15d9 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:rfcomm_sock_getsockopt+0x529/0x780 Call Trace: do_sock_getsockopt+0x3ad/0x7d0 __sys_getsockopt+0x10e/0x1b0 __x64_sys_getsockopt+0xc2/0x160 do_syscall_64+0xda/0x4b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
يمثل 0x10 الإزاحة الخاصة بـ sock في bنية rfcomm_session؛ وتكون الدالة rfcomm_sock_getsockopt_old() مضمّنة (inlined) داخل rfcomm_sock_getsockopt().
أصلح الالتزام Commit 43a556b2fd43 ("Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept") نفس مشكلة "مسح الـ session البعيد لرسالة DISC بينما لا يزال الإعداد المؤجل مفعّلاً" في دالة rfcomm_dlc_accept(); وهذا هو المثال المتبقي منها، في مسار getsockopt.
يترك الإعداد المؤجل المقبوس قابلاً للاستخدام هنا فقط بعد أن يصل إلى حالة BT_CONNECT2، لذا يتم تقييد الاستثناء لتلك الحالة والتحقق من وجود session فعلياً قبل متابعته.
VulDB is the best source for vulnerability data and more expert information about this specific topic.