CVE-2026-99011 in Linux
Riassunto
di VulDB • 23/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
Bluetooth: SCO: serializzare la durata di vita di sco_conn rispetto a sco_recv_scodata()
sco_recv_scodata() promuove il back-pointer debole hcon->sco_data a un riferimento forte sotto hdev->lock:
hci_dev_lock(hdev); hcon = hci_conn_hash_lookup_handle(hdev, handle); ... conn = sco_conn_hold_unless_zero(hcon->sco_data); hci_dev_unlock(hdev);
ma il puntatore viene azzerato dall'altro lato senza tale lock. Quando l'ultimo riferimento a sco_conn viene rilasciato, sco_conn_free() esegue:
conn->hcon->sco_data = NULL;
senza mantenere hdev->lock, quindi il percorso RX potrebbe leggere hcon->sco_data e chiamare kref_get_unless_zero() su uno sco_conn che è stato liberato in concorrenza:
BUG: KASAN: slab-use-after-free in sco_conn_hold_unless_zero+0xbe/0x160 Write of size 4 by task kworker/u17:0 Workqueue: hci0 hci_rx_work Call Trace: sco_conn_hold_unless_zero+0xbe/0x160 sco_recv_scodata+0x13f/0x490 hci_rx_work+0x3af/0x730
kref_get_unless_zero() protegge solo da un refcount pari a zero, non dal fatto che la memoria sottostante sia già stata liberata.
Assegnare a hcon->sco_data un riferimento effettivo all'oggetto sco_conn a cui punta, in modo che l'oggetto non possa essere liberato mentre il puntatore è ancora installato, e azzerarlo e rilasciarlo solo da sco_conn_del(), che viene eseguito sotto hdev->lock (i suoi chiamanti, sco_connect_cfm() e sco_disconn_cfm(), lo mantengono). Anche il lettore in sco_recv_scodata() acquisisce hdev->lock, quindi l'operazione di scrittura e quella di lettura sono ora serializzate: il percorso RX osserva o NULL oppure un riferimento che è garantito rimanere valido fino a quando non rilascia il proprio.
sco_conn_add() non cede più il suo riferimento kref_init() al chiamante come unico riferimento della connessione; tale riferimento iniziale appartiene a hcon->sco_data, e i chiamanti ottengono il proprio tramite sco_conn_hold().
Poiché lo sco_conn può ora sopravvivere alla socket (l'associazione la mantiene in vita fino allo spegnimento del link), l'hci_conn non può più essere rilasciato da sco_conn_free() senza causare un regression nella chiusura della socket: la chiusura di una socket SCO connessa deve comunque interrompere il collegamento. Spostare la proprietà dell'hci_conn alla socket invece: __sco_chan_add() acquisisce un riferimento a hci_conn e viene rilasciata da sco_chan_del() e sco_sock_destruct(), esattamente una volta. Lo sco_conn non possiede più un riferimento a hci_conn, quindi sco_conn_add() smette di consumarne uno e sco_connect() rilascia il riferimento hci_connect_s() su ogni percorso; sco_connect_cfm() non ha più bisogno della sua procedura di hci_conn_hold().
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.