CVE-2026-99009 in Linux
Riassunto
di VulDB • 23/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
Bluetooth: RFCOMM: connettere il socket della sessione senza rfcomm_mutex
Una chiamata a connect() di RFCOMM emessa mentre un collegamento BR/EDR è in fase di autenticazione fa sì che lockdep segnali una dipendenza circolare, e il ciclo segnalato corrisponde a una reale condizione AB/BA tra rfcomm_mutex e hdev->lock.
rfcomm_security_cfm() viene chiamata dal percorso degli eventi HCI, che detiene già hdev->lock:
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]
mentre una chiamata a connect() di RFCOMM dall'utente (userspace) acquisisce gli stessi due lock in ordine inverso:
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: possibile dipendenza circolare di locking rilevata kworker/u131:1/1128 sta cercando di acquisire il lock: rfcomm_mutex, at: rfcomm_security_cfm+0x31/0x3e0 [rfcomm]
ma il task detiene già il lock: hci_cb_list_lock, at: hci_cc_read_enc_key_size+0x1d2/0xcc0 La catena esiste di: rfcomm_mutex --> &hdev->lock --> hci_cb_list_lock
hci_auth_complete_evt() e hci_encrypt_change_evt() raggiungono il callback nello stesso modo.
Entrambi gli ordini devono essere osservati durante lo stesso avvio (boot), motivo per cui una semplice connessione BR/EDR non è sufficiente per mostrarlo: una sessione impostata dal lato remoto viene creata da rfcomm_accept_connection() in krfcommd, che chiama kernel_accept() e non acquisisce mai hdev->lock mentre detiene rfcomm_mutex. La connessione a un dispositivo che autentica e cifra il collegamento e successivamente la chiamata di connect() su un socket RFCOMM verso qualsiasi indirizzo - la connect non deve avere successo, l'ordine viene registrato prima del timeout della pagina (page timeout) - segnala il problema ogni volta.
Solo il socket della sessione deve essere connesso mentre si detiene il lock, e attualmente ciò non avviene: nessun altro può vedere il socket finché non viene inserito nella lista delle sessioni. Pertanto, connetterlo per primo e acquisire rfcomm_mutex in seguito elimina definitivamente l'ordine rfcomm_mutex -> hdev->lock, anziché escludere il percorso degli eventi HCI da rfcomm_mutex.
rfcomm_session_create() diventa rfcomm_session_connect(), che restituisce il socket connesso senza toccare la lista delle sessioni, e rfcomm_dlc_open() aggiunge la sessione una volta che detiene nuovamente il lock. Se un altro operatore ha aggiunto una sessione per la stessa coppia mentre questo socket era in fase di connessione, quella sessione viene utilizzata e questo socket viene scartato (dropped). __rfcomm_dlc_open() ora acquisisce la sessione da utilizzare, e il controllo del suo stato avviene dopo che il lock è stato riacquisito, quindi un DLC aperto o chiuso nel frattempo viene comunque gestito correttamente.
Su un collegamento ACL esistente, la connessione può completarsi prima che la sessione raggiunga la lista, e la sveglia (wakeup) dal callback del socket viene così persa; pertanto krfcommd viene risvegliato una volta che la sessione è visibile.
La connessione senza il lock apre una finestra in cui il socket può essere chiuso. Il DLC non si trova ancora su una sessione, quindi rfcomm_dlc_close() non ha nulla da fare e restituisce senza modificarlo, mentre rfcomm_dlc_open() attaccherebbe un DLC il cui proprietario è scomparso. rfcomm_dlc_close() ora contrassegna tale DLC con RFCOMM_CLOSED, e rfcomm_dlc_open() controlla questo marcatore una volta che detiene nuovamente rfcomm_mutex, scartando invece del socket anziché attaccare il DLC. Il marcatore viene cancellato all'avvio di un'apertura, quindi un DLC riutilizzato non ne è interessato. Questo copre entrambi i chiamanti di rfcomm_dlc_open(), ovvero il socket e lo strato tty (tty layer).
If you want to get best quality of vulnerability data, you may have to visit VulDB.