CVE-2026-98455

Linux nüvəsində aşağıdakı zəiflik aradan qaldırılmışdır: Bluetooth: RFCOMM: RFCOMM_CONNINFO-da dlc->session-ın NULL dereference xətasının düzəldilməsi RFCOMM_CONNINFO getsockopt idarəçisi, təxirə salınmış quraşdırma (deferred setup) aktiv olduğu müddətcə qoşulmamış soketi qəbul edir: 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 dəyişəni, BT_DEFER_SETUP aktiv olan dinləyici soketdə gələn bağlantı üçün rfcomm_connect_ind() alt soket yaratdıqda rfcomm_sock_init() funksiyasında təyin edilir və daha sonra heç vaxt sıfırlanmır. Lakin sessiya onun altında yox ola bilər. rfcomm_recv_disc() funksiyası dlc vəziyyətini ləğv etməzdən əvvəl məcburi şəkildə təyin edir: d->state = BT_CLOSED; __rfcomm_dlc_close(d, err); __rfcomm_dlc_close() funksiyasındakı RFCOMM_DEFER_SETUP erkən geri dönüşü yalnız BT_CONNECT, BT_CONFIG, BT_OPEN və BT_CONNECT2 vəziyyətlərini əhatə edir, buna görə də vəziyyət artıq BT_CLOSED olduqda həmin switch uyğun gəlmir və funksiya rfcomm_dlc_unlink()-ə keçir ki, bu da d->defer_setup 1 olaraq qalarkən d->session = NULL təyin edir. Buna görə də, həmin nöqtədən sonra qəbul edilmiş soket üzərində çağırılan getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO), -ENOTCONN yolunu ötürür — çünki sk->sk_state BT_CLOSED olsa da, dlc->defer_setup hələ də təyin edilib — və NULL sessiyanın dereference-ını yerinə yetirir. Heç bir yarış şərtinin (race condition) olması tələb olunmur: DISC emal edildikdən sonra dereference qeydsiz şəkildə baş verir. Bu problem /dev/vhci vasitəsilə emulyasiya edilmiş BR/EDR tərəfdaşı ilə QEMU altında KASAN nüvəsində təkrar istehsal edilmişdir: tərəfdaş ACL bağlantısını qurur, RFCOMM PSM üzərində L2CAP açır, sessiya başladır və BT_DEFER_SETUP ilə bağlanmış kanal üçün SABM göndərir və soket qəbul edildikdən sonra həmin dlci üçün DISC göndərir. Sonra qəbul edilmiş soket üzərində getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) çağırışı aşağıdakına səbəb olur: 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: <TASK> 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 </TASK> 0x10, struct rfcomm_session-da sock elementinin ofsetidir; rfcomm_sock_getsockopt_old() funksiyası rfcomm_sock_getsockopt() daxilinə inlined edilmişdir. 43a556b2fd43 ("Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept") commit-i rfcomm_dlc_accept() funksiyasındakı eyni "uzaq DISC, təxirə salınmış quraşdırma hələ də qeyd olunduğu halda sessiyanı təmizləyir" problemini düzəltmişdir; bu isə həmin problemin getsockopt yolunda qalan son nümunəsidir. Təxirə salınmış quraşdırma burada soketi yalnız BT_CONNECT2 vəziyyətinə çatdıqda istifadə edilə bilən edir, ona görə də istisna həmin vəziyyətlə məhdudlaşdırılır və izləməzdən əvvəl sessiyanın həqiqətən mövcud olub-olmadığı yoxlanılır.