CVE-2026-53357

Linux kernel'de aşağıdaki güvenlik açığı giderilmiştir: Bluetooth: l2cap_sock_cleanup_listen() ile l2cap_conn_del() arasındaki UAF hatası düzeltildi bt_accept_dequeue(), henüz kabul edilmemiş bir alt öğeyi üst kabul kuyruğundan ayırır ve geri dönmeden önce release_sock() işlemini gerçekleştirir; bu nedenle döndürülen sk'nın çağırıcı referansı yoktur ve kilitli değildir. l2cap_sock_cleanup_listen(), dinleme soketi kapatıldığında bu alt öğeleri tarar. Eşzamanlı bir HCI bağlantı kesilmesi, hci_rx_work -> l2cap_conn_del() sürecini tetikler; bu süreç l2cap_chan_del() + l2cap_sock_kill() fonksiyonlarını çalıştırarak alt sk'yı ve onun l2cap_chan bileşenini serbest bırakır; ardından cleanup_listen() her ikisini de kullanmaya çalışır: BUG: KASAN: slab-use-after-free in l2cap_sock_kill l2cap_sock_kill / l2cap_sock_cleanup_listen / __x64_sys_close Serbest bırakan: l2cap_conn_del -> l2cap_sock_close_cb -> l2cap_sock_kill Bu durum, aynı alanda halihazırda bulunan iki düzeltmeden farklıdır: e83f5e24da741 ("Bluetooth: serialize accept_q access") commit'i, accept_q listesini/poll işlemini serileştirir ve bt_accept_dequeue() içinde geçici referanslar alır; CVE-2025-39860 ise l2cap_sock_release() içindeki lock_sock() altında cleanup_listen() çağrısını yaparak kullanıcı alanı close()/accept() yarışını serileştirir. Her iki çözüm de hci_rx_work üzerinden çalışan l2cap_conn_del() işlemini kapsamadığından, bu UAF durumu mevcut bluetooth/master sürümünde hala yeniden üretilmektedir. Referans kaynağında alınmıştır: bt_accept_dequeue(), release_sock() işleminden önce sk hala kilitliyken sock_hold() yapar; çağıranlar ise sock_put() yapar. cleanup_listen(), kısa süreli bir alt sk kilidi altında (l2cap_sock_teardown_cb() ile serileştirerek) l2cap_chan_hold_unless_zero() ile chan bileşenini sabitler, bunu l2cap_chan_lock() öncesinde bırakır ve SOCK_DEAD durumunda mükerrer l2cap_sock_kill() işlemini atlar. conn->lock burada alınmamıştır: cleanup_listen() üst sk kilidi altında çalışır ve aksi takdirde conn->lock -> chan->lock -> sk_lock (lockdep) sırasını tersine çevirirdi. KASAN/SMP: Bu değişiklikten önce, ayrıcalıksız bir listen/close ile HCI-disconnect yarışı her çalıştırmada 12 adet use-after-free raporu üretiyordu; bluetooth/master üzerinde yapılan 1600'den fazla yarış iterasyonundan sonra 0 rapor ve hiçbir lockdep raporu oluşmamıştır.