CVE-2026-90087 in Linux
Riassunto
di VulDB • 17/09/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
Bluetooth: non perdere (leak) un hci_conn quando una seconda connessione LE viene rifiutata
create_le_conn_complete() decide se la connessione fallita è ancora in sospetto confrontandola con hci_lookup_le_connect(), che restituisce la prima connessione LE nello stato BT_CONNECT. Questo funziona correttamente solo mentre c'è al massimo una connessione in sospeso.
Possono essercene due in sospeso. Le connessioni create sul percorso di scansione passiva si trovano nello stato BT_CONNECT con HCI_CONN_SCANNING impostato e sono invisibili a hci_lookup_le_connect() finché hci_le_create_conn_sync() non cancella il flag quando viene emesso il relativo comando; pertanto, la guardia -EBUSY in hci_connect_le() non impedisce l'accodamento di una seconda connessione mentre la prima è ancora sul percorso di scansione. Quando due connessioni si trovano contemporaneamente nello stato BT_CONNECT, la lookup può restituire una connessione mentre create_le_conn_complete() segnala il fallimento dell'altra; l'uscita anticipata fa quindi perdere l'errore e hci_conn_failed() non viene mai eseguito sulla connessione che ha fallito.
Il controller rifiuta anche una seconda HCI_OP_LE_CREATE_CONN emessa mentre la creazione di un'altra connessione è ancora in corso, come specificato nel Core Spec Vol 4, Part E. La specifica prevede "Command Disallowed" (Comando non consentito); il bcm43438 osservato qui risponde invece con un codice di errore LMP/LL, che bt_to_errno() mappa a -EPROTO (-71) nel log sottostante.
La connessione persa rimane indefinitamente nello stato BT_CONNECT e, poiché hci_connect_le() rifiuta le chiamate mentre hci_lookup_le_connect() trova qualcosa, ogni tentativo successivo di raggiungere qualsiasi peer fallisce con -EBUSY e nessun comando raggiunge affatto il controller.
Rilevato su un bcm43438 con due peer BLE interrogati sullo stesso intervallo (lo stato 5 è BT_CONNECT; entrambi i handle sono UNSET, allocati dall'ida sopra HCI_CONN_HANDLE_MAX):
Bluetooth: hci1: Opcode 0x2013 failed: -71
# hcitool con < LE 14:9C:EF:03:68:81 handle 3840 state 5 lm CENTRAL < LE C4:D3:6A:8C:B5:38 handle 3841 state 5 lm CENTRAL
Una cattura btmon effettuata nei successivi dieci minuti di tentativi di connessione non contiene affatto HCI_OP_LE_CREATE_CONN; le connessioni LE in uscita non si recuperano finché l'adattatore non viene resettato. Con questa modifica, lo stesso scenario gestisce correttamente il rifiuto della connessione e i collegamenti successivi con entrambi i peer avvengono regolarmente.
Interrogare la connessione stessa anziché il dispositivo.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.