CVE-2026-80819

Linux kernel-də aşağıdakı zəiflik aradan qaldırılmışdır: Bluetooth: RFCOMM: təxirə salınmış quruluşun qəbulu üçün rfcomm_mutex istifadə edin rfcomm_sock_recvmsg() funksiyası heç bir RFCOMM kilidi saxlamadan rfcomm_dlc_accept() funksiyasını çağıraraq təxirə salınmış quruluşu tamamlayır: if (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) { rfcomm_dlc_accept(d); return 0; } və rfcomm_dlc_accept() ilk sətrində sessiyanı dereference edir: struct sock *sk = d->session->sock->sk; d->session obyektinə toxunan digər bütün yollar rfcomm_mutex altında işləyir: rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn() və rfcomm_process_sessions() vasitəsilə RFCOMM axını (thread). Hətta rfcomm_connect_ind() funksiyasının "rfcomm_lock() altında çağırıldığı" sənədləşdirilib. Bu çağırış nöqtəsi onu ötürən yeganə yerdir. RFCOMM_DEFER_SETUP biti, __rfcomm_dlc_close() test_and_clear zamanı qalib gəldikdə erkən geri döndüyü üçün, qəbul prosesini ləğv etmə ilə ardıcıl hala gətirmiş kimi görünür. Lakin rfcomm_recv_disc() əvvəlcə vəziyyəti məcburi dəyişir: d->state = BT_CLOSED; __rfcomm_dlc_close(d, err); və erkən geri dönmə yalnız BT_CONNECT, BT_CONFIG, BT_OPEN və BT_CONNECT2 hallarını əhatə edir. Vəziyyət artıq BT_CLOSED olduğu üçün həmin switch uyğun gəlmir, bit heç vaxt yoxlanılmır və __rfcomm_dlc_close() funksiyası d->session = NULL təyin edən rfcomm_dlc_unlink() funksiyasına keçir. Beləliklə, təxirə salınmış dlc üzərində uzaqdan göndərilən DISC, RFCOMM_DEFER_SETUP bitini aktiv saxlayaraq sessiyanı təmizləyir. Növbəti recvmsg() isə test_and_clear şərtini ödəyir və NULL olan sessiyanı dereference edir. Heç bir zaman pəncərəsinə ehtiyac yoxdur: DISC emal edildikdən sonra dereference qeydsiz şəkildə baş verir. rfcomm_dlc_accept() funksiyasına rfcomm_dlc_open() və rfcomm_dlc_close() ilə eyni struktur verilsin: rfcomm_mutex alan və sessiyanı yenidən yoxlayan ixrac olunmuş (exported) bir wrapper, həmçinin mutexi artıq saxlayan iki daxili çağıranın istifadə etməyə davam edəcəyi __rfcomm_dlc_accept() funksiyası. Problem /dev/vhci üzərində emulyasiya edilmiş BR/EDR peer ilə KASAN + PROVE_LOCKING nüvəsində təkrarlandı: peer ACL bağlantısını qurur, RFCOMM PSM üzərində L2CAP açır, sessiya başladır, BT_DEFER_SETUP ilə bağlanmış kanal üzərində dlc açır və soket qəbul edildikdən sonra DISC göndərir. Qəbul edilmiş soket üzərində recv() çağırışı aşağıdakıları törədir: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rfcomm_dlc_accept+0x54/0x350 Call Trace: rfcomm_sock_recvmsg+0x1cd/0x230 sock_recvmsg+0x166/0x1c0 __sys_recvfrom+0x20d/0x300 0x10, struct rfcomm_session içindəki sock elementinin ofsetidir. Bu yamama (patch) ilə eyni sınaq recv()-in 0 qaytarması və heç bir hesabat olmadan tamamlanır, lockdep isə sakit qalır ki, bu da axın tərəfində olduğu kimi, bu yolda da lock_sock-dan əvvəl rfcomm_mutex-in hələ də alındığını təsdiqləyir.