CVE-2026-80819

Linux kernel'de aşağıdaki güvenlik açığı giderilmiştir: Bluetooth: RFCOMM: ertelenmiş kurulum kabulü için rfcomm_mutex kullanımı rfcomm_sock_recvmsg(), herhangi bir RFCOMM kilidi tutmadan rfcomm_dlc_accept() fonksiyonunu çağırarak ertelenmiş bir kurulumu tamamlar: if (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) { rfcomm_dlc_accept(d); return 0; } ve rfcomm_dlc_accept() ilk satırında oturum referansını çözer (dereference): struct sock *sk = d->session->sock->sk; d->session yapısına erişen diğer tüm yollar rfcomm_mutex altında çalışır: rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn() ve rfcomm_process_sessions() üzerinden çalışan RFCOMM iş parçacığı. Hatta rfcomm_connect_ind() fonksiyonunun "rfcomm_lock() altında çağrıldığı" belgelenmiştir. Bu çağrı noktası, bu işlemi atlayan tek yerdir. RFCOMM_DEFER_SETUP biti, __rfcomm_dlc_close() test_and_clear işlemini kazandığında erken döndüğü için kabul işlemini kapatma işlemine karşı serileştiriyor gibi görünmektedir. Ancak rfcomm_recv_disc() önce durumu zorlar: d->state = BT_CLOSED; __rfcomm_dlc_close(d, err); ve erken dönüş yalnızca BT_CONNECT, BT_CONFIG, BT_OPEN ve BT_CONNECT2 durumlarını kapsar. Durum zaten BT_CLOSED olduğunda ilgili switch eşleşmez, bit kontrol edilmez ve __rfcomm_dlc_close() fonksiyonu d->session = NULL olarak ayarlayan rfcomm_dlc_unlink() kısmına geçer. Bu nedenle, ertelenmiş bir dlc üzerinde gerçekleşen uzak bir DISC işlemi, RFCOMM_DEFER_SETUP bitini ayarlı bırakırken oturumu temizler. Bir sonraki recvmsg() çağrısı test_and_clear aşamasını geçer ve NULL olan bir oturum referansını çözmeye çalışır. Herhangi bir zamanlama penceresine ihtiyaç yoktur: DISC işlemi tamamlandıktan sonra referans çözme işlemi koşulsuzdur. rfcomm_dlc_accept() fonksiyonuna, rfcomm_dlc_open() ve rfcomm_dlc_close() ile aynı yapı verilmiştir: rfcomm_mutex alan ve oturumu yeniden kontrol eden dışa aktarılmış bir sarmalayıcı (wrapper) ve halihazırda mutex tutan iki dahili çağırıcının kullanmaya devam ettiği bir __rfcomm_dlc_accept(). Hata, /dev/vhci üzerinden emüle edilen bir BR/EDR eşiyle KASAN + PROVE_LOCKING çekirdeğinde yeniden üretilmiştir: Eş cihaz bir ACL bağlantısı kurar, RFCOMM PSM üzerinde L2CAP'ı açar, bir oturum başlatır, BT_DEFER_SETUP ile bağlı bir kanal üzerinde dlc açar ve soket kabul edildikten sonra DISC gönderir. Kabul edilen soketteki recv() şu hataya yol açar: 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çindeki sock yapısının ofsetidir. Bu yama ile aynı çalışma süreci, recv() fonksiyonunun 0 döndürmesiyle rapor oluşmadan tamamlanır ve lockdep sessiz kalır; bu da rfcomm_mutex'in, iş parçacığı tarafında olduğu gibi bu yolda da lock_sock öncesinde alındığını doğrular.