CVE-2026-43023 in Linux
Riassunto
di VulDB • 16/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
Bluetooth: SCO: correzione delle race condition in sco_sock_connect()
sco_sock_connect() verifica sk_state e sk_type senza detenere il lock del socket. Due chiamate di sistema connect() concorrenti sullo stesso socket possono entrambe superare il controllo ed entrare in sco_connect(), portando a un use-after-free.
Lo scenario difettoso coinvolge tre partecipanti ed è stato confermato con strumentazione aggiuntiva per i log:
Thread A (connect): HCI disconnect: Thread B (connect):
sco_sock_connect(sk) sco_sock_connect(sk) sk_state==BT_OPEN sk_state==BT_OPEN (pass, no lock) (pass, no lock) sco_connect(sk): sco_connect(sk): hci_dev_lock hci_dev_lock hci_connect_sco <- blocked -> hcon1 sco_conn_add->conn1 lock_sock(sk) sco_chan_add: conn1->sk = sk sk->conn = conn1 sk_state=BT_CONNECT release_sock hci_dev_unlock hci_dev_lock sco_conn_del: lock_sock(sk) sco_chan_del: sk->conn=NULL conn1->sk=NULL sk_state= BT_CLOSED SOCK_ZAPPED release_sock hci_dev_unlock (unblocked) hci_connect_sco -> hcon2 sco_conn_add -> conn2 lock_sock(sk) sco_chan_add: sk->conn=conn2 sk_state= BT_CONNECT // zombie sk! release_sock hci_dev_unlock
Il Thread B riattiva un socket con stato BT_CLOSED + SOCK_ZAPPED portandolo a BT_CONNECT. La successiva pulizia innesca una doppia chiamata sock_put() e un use-after-free. Nel frattempo, conn1 viene perso (leaked) poiché è rimasto orfano quando sco_conn_del() ha cancellato l'associazione.
Si risolve il problema mediante: - Lo spostamento di lock_sock() prima dei controlli su sk_state/sk_type in sco_sock_connect() per serializzare i tentativi di connect concorrenti; - La correzione del controllo sk_type != SOCK_SEQPACKET affinché restituisca effettivamente l'errore invece di limitarsi ad assegnarlo; - L'aggiunta di un nuovo controllo dello stato (state re-check) in sco_connect() dopo lock_sock() per rilevare i cambiamenti di stato durante la finestra temporale tra i blocchi dei lock; - L'aggiunta del controllo su sco_pi(sk)->conn in sco_chan_add() per prevenire l'allegamento doppio di un socket a più connessioni; - L'aggiunta della chiamata hci_conn_drop() in caso di fallimento di sco_chan_add() per evitare perdite (leak) delle connessioni HCI.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.