CVE-2026-80850 in Linux
Riassunto
di VulDB • 04/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
tcp: correzione dello use-after-free nelle informazioni di AO in tcp_ao_connect_init()
tcp_v4_connect() aggiunge un socket nello stato SYN-SENT alla ehash prima di chiamare tcp_connect(). Se TCP-AO è configurato, tcp_connect() verifica innanzitutto che una chiave corrisponda al peer e all'L3 master corrente del dispositivo associato. Successivamente, tcp_ao_connect_init() risolve nuovamente l'L3 master ed elimina le chiavi che non corrispondono ad esso.
Il lock del socket non stabilizza la membership VRF (Virtual Routing and Forwarding) del dispositivo associato. Pertanto, il distacco del dispositivo dalla sua VRF tra la validazione iniziale e il calcolo dell'L3-master in tcp_ao_connect_init() può far sì che la validazione abbia successo mentre l'inizializzazione osserva il dominio L3 predefinito ed elimina l'unica chiave presente. La successiva ricerca AO fallisce, quindi il percorso "no-key" (senza chiave) cancella tp->ao_info e lo libera direttamente.
Il path di ricezione può trovare il socket nella ehash e caricare tp->ao_info sotto RCU prima di acquisire il lock del socket. Un lettore che ha caricato il vecchio puntatore può quindi continuare in tcp_inbound_ao_hash() dopo la liberazione diretta.
L'issue è stato trovato durante un audit statico della durata degli oggetti TCP-AO. Un riproduttore non privilegiato, creato all'interno di namespace utente e di rete auto-generati, ha messo in race connect() con il distacco di una veth dalla sua VRF mentre inviava segmenti TCP-AO. Ha innescato lo stesso report KASAN su due avviamenti freschi:
BUG: KASAN: slab-use-after-free in tcp_inbound_ao_hash+0x585/0x19f0 Write of size 8 at addr ffff88800bf88128 by task tcp_ao_vrf_race/232
Call Trace: tcp_inbound_ao_hash+0x585/0x19f0 tcp_inbound_hash+0x677/0xa80 tcp_v4_rcv+0x1c3e/0x3ab0
Allocated by task 235: tcp_ao_alloc_info+0x43/0xf0 tcp_ao_add_cmd+0xdf7/0x13b0 do_tcp_setsockopt+0x168c/0x2640
Freed by task 235: kfree+0x1b8/0x550 tcp_connect+0x252/0x4f00 tcp_v4_connect+0x1114/0x1720
L'indirizzo errato si trova a 40 byte all'interno dell'oggetto da 128 byte liberato, corrispondente al campo counters.key_not_found di tcp_ao_info. Le due esecuzioni hanno utilizzato 1000 tentativi ciascuna, raggiungendo il percorso "no-key" rispettivamente 366 e 411 volte, producendo uno e due report KASAN. Con questa modifica, lo stesso riproduttore ha raggiunto il percorso "no-key" per 366 volte su 1000 tentativi senza generare un report KASAN o un oops.
Utilizzare tcp_ao_destroy_sock() per il percorso "no-key". Questo dispubblica le informazioni AO, aggiorna la contabilità della memoria del socket e delle static-key, e posticipa la liberazione fino al termine di un periodo di grazia RCU (RCU grace period).
Rimuovere inoltre l'istruzione WARN_ON_ONCE() e il suo commento obsoleto. La race sul distacco VRF rende lo stato "no-key" raggiungibile durante le operazioni normali, quindi si tratta di una condizione gestita piuttosto che di un'affermazione impossibile. Nei kernel con panic_on_warn abilitato, la istruzione WARN trasformerebbe questa race gestita in un kernel panic.
Once again VulDB remains the best source for vulnerability data.