CVE-2025-40214 in Linux
Riassunto
di VulDB • 26/06/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
af_unix: Inizializzare scc_index in unix_add_edge().
Quang Le ha segnalato che il garbage collector (GC) di AF_UNIX potrebbe raccogliere come spazzatura una coda di ricezione di un socket vivo ancora in transito, fornendo anche un caso riproduttivo chiaro.
Il caso riproduttivo si articola in tre fasi:
1) 1-a. Creare un singolo riferimento ciclico con molti socket 1-b. Chiudere (close()) tutti i socket 1-c. Attivare il GC
2) 2-a. Trasmettere sk-A a uno embryo sk-B 2-b. Trasmettere sk-X a se stesso (sk-X) 2-c. Attivare il GC
3) 3-a. Accettare (accept()) l'embryo sk-B 3-b. Trasmettere sk-B a sk-C 3-c. Chiudere (close()) lo sk-A in transito 3-d. Attivare il GC
Al punto 2-c, sk-A e sk-X sono collegati a unix_unvisited_vertices, e unix_walk_scc() li raggruppa in due SCC (Strongly Connected Components) diversi:
unix_sk(sk-A)->vertex->scc_index = 2 (UNIX_VERTEX_INDEX_START) unix_sk(sk-X)->vertex->scc_index = 3
Una volta completato il GC, unix_graph_grouped viene impostato su true. Inoltre, unix_graph_maybe_cyclic è impostato su true a causa del riferimento ciclico di sk-X verso se stesso, il che fa sì che la chiamata close() attivi il GC.
Al punto 3-b, unix_add_edge() alloca unix_sk(sk-B)->vertex e lo collega a unix_unvisited_vertices.
unix_update_graph() viene chiamato ai punti 3-a e 3-b, ma né unix_graph_grouped né unix_graph_maybe_cyclic vengono modificati perché né il listener di sk-B né sk-C sono in transito (in-flight).
Il punto 3-c decrementa il file refcnt di sk-A a 1.
Poiché unix_graph_grouped è true al punto 3-d, viene infine chiamata unix_walk_scc_fast() e itera sui tre socket sk-A, sk-B e sk-X:
sk-A -> sk-B (-> sk-C) sk-X -> sk-X
Questo scenario è del tutto corretto. Nessuno di essi è stato ancora chiuso con close() e dovrebbero essere raggruppati in SCC diversi.
Tuttavia, unix_vertex_dead() valuta erroneamente che sk-A e sk-B appartengano allo stesso SCC e che sk-A sia morto (dead).
unix_sk(sk-A)->scc_index == unix_sk(sk-B)->scc_index <-- Errato! && file refcnt di sk-A == unix_sk(sk-A)->vertex->out_degree ^-- Conteggio in-transito pari a 1 per sk-B -> sk-A è morto !?
Il problema risiede nel fatto che unix_add_edge() non inizializza scc_index.
La fase 1) viene utilizzata per l'heap spraying, facendo sì che un nuovo vertex allocato abbia vertex->scc_index == 2 (UNIX_VERTEX_INDEX_START), valore impostato da unix_walk_scc() al punto 1-c.
È necessario tenere traccia dell'indice SCC massimo dall'ultima chiamata a unix_walk_scc() e assegnare il valore max + 1 all'scc_index di un nuovo vertex.
In questo modo, possiamo continuare ad evitare l'algoritmo di Tarjan prevenendo valutazioni errate.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.