CVE-2026-99009

Linux kernel'de aşağıdaki güvenlik açığı giderilmiştir: Bluetooth: RFCOMM: oturum soketinin rfcomm_mutex olmadan bağlanması Bir BR/EDR bağlantısı kimlik doğrulaması yapılırken başlatılan bir RFCOMM connect() işlemi, lockdep'in dairesel bir bağımlılık raporlamasına neden olur ve bildirilen döngü, rfcomm_mutex ile hdev->lock arasında gerçek bir AB/BA durumudur. rfcomm_security_cfm(), halihazırda hdev->lock kilidine sahip olan HCI olay yolu üzerinden çağrılır: hci_rx_work() hci_event_packet() hci_cc_read_enc_key_size() [hdev->lock] hci_encrypt_cfm() [hci_cb_list_lock] rfcomm_security_cfm() [rfcomm_mutex] Kullanıcı alanından gelen bir RFCOMM connect() işlemi ise aynı iki kilidi ters sırada alır: rfcomm_sock_connect() rfcomm_dlc_open() [rfcomm_mutex] __rfcomm_dlc_open() rfcomm_session_create() kernel_connect() l2cap_sock_connect() l2cap_chan_connect() [hdev->lock] WARNING: possible circular locking dependency detected kworker/u131:1/1128 is trying to acquire lock: rfcomm_mutex, at: rfcomm_security_cfm+0x31/0x3e0 [rfcomm] but task is already holding lock: hci_cb_list_lock, at: hci_cc_read_enc_key_size+0x1d2/0xcc0 Chain exists of: rfcomm_mutex --> &hdev->lock --> hci_cb_list_lock hci_auth_complete_evt() ve hci_encrypt_change_evt() fonksiyonları geri çağırma işlemine aynı yolla ulaşır. Her iki sıranın da aynı önyükleme sırasında görülmesi gerekir; bu nedenle tek başına bir BR/EDR bağlantısı bunu göstermek için yeterli değildir: Uzak tarafça kurulan bir oturum, krfcommd içindeki rfcomm_accept_connection() tarafından oluşturulur; bu fonksiyon kernel_accept() işlemini çağırır ve rfcomm_mutex altında asla hdev->lock kilidini almaz. Bağlantıyı kimlik doğrulayan ve şifreleyen bir cihazı bağlamak ve ardından herhangi bir adrese doğru bir RFCOMM soketi üzerinde connect() çağırmak -bağlantının başarılı olması gerekmez, sıra sayfa zaman aşımından önce kaydedilir- bunu her seferinde raporlar. Sadece oturum soketinin kilit tutulurken bağlanması gerekir ancak mevcut durumda böyle değildir: Soket oturum listesine eklenmeden önce başka hiçbir şey soketi göremez. Bu nedenle, önce bağlantıyı kurmak ve ardından rfcomm_mutex kilidini almak, HCI olay yolunu rfcomm_mutex dışında tutmaktan ziyade, rfcomm_mutex -> hdev->lock sırasını kalıcı olarak ortadan kaldırır. rfcomm_session_create(), oturum listesine dokunmadan bağlı soketi döndüren rfcomm_session_connect() haline gelir ve rfcomm_dlc_open(), kilidi tekrar aldığında oturumu ekler. Eğer bu soket bağlanırken başka bir açıcı aynı çift için bir oturum eklediyse, o oturum kullanılır ve bu soket düşürülür. __rfcomm_dlc_open() artık kullanması gereken oturumu alır ve durum kontrolü kilit yeniden alındıktan sonra çalışır, böylece bu süre zarfında açılan veya kapatılan bir DLC hala işlenir. Mevcut bir ACL bağlantısı üzerinden, bağlantı oturum listeye ulaşmadan tamamlanabilir ve bu durumda soket geri çağırmasından gelen uyandırma sinyali kaybolur; dolayısıyla oturum görünür olduğunda krfcommd bir kez uyandırılır. Kilit olmadan bağlanmak, soketin kapatılabileceği bir pencere açar. DLC henüz bir oturumda değildir, bu nedenle rfcomm_dlc_close() yapılacak bir şey bulamaz ve ona dokunmadan döner; rfcomm_dlc_open() ise sahibi gitmiş bir DLC'yi iliştirebilir. rfcomm_dlc_close() artık böyle bir DLC'yi RFCOMM_CLOSED ile işaretler ve rfcomm_dlc_open(), rfcomm_mutex kilidini tekrar aldığında bu işareti kontrol eder ve DLC'yi iliştirmek yerine soketi düşürür. İşaret, bir açma işlemi başladığında temizlenir, böylece yeniden kullanılan bir DLC etkilenmez. Bu durum, rfcomm_dlc_open()'ın her iki çağırıcısını, yani soket ve tty katmanını kapsar.