CVE-2025-40214 in Linux
Zusammenfassung
von VulDB • 22.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
af_unix: Initialisieren von scc_index in unix_add_edge().
Quang Le meldete, dass der AF_UNIX-Garbage-Collector (GC) eine Empfangswarteschlange eines aktiven, noch in der Übertragung befindlichen Sockets garbage-collecten könnte, wobei er ein gut funktionierendes Reproduktionsszenario (Repro) bereitstellte.
Das Reproduktionsszenario besteht aus drei Phasen:
1) 1-a. Erzeugen eines einzelnen zyklischen Verweises mit vielen Sockets 1-b. Schließen (close()) aller Sockets 1-c. Auslösen des GC
2) 2-a. Übergeben von sk-A an den Embryo sk-B 2-b. Übergeben von sk-X an sk-X 2-c. Auslösen des GC
3) 3-a. Akzeptieren (accept()) des Embryos sk-B 3-b. Übergeben von sk-B an sk-C 3-c. Schließen (close()) des in der Übertragung befindlichen sk-A 3-d. Auslösen des GC
Ab Schritt 2-c sind sk-A und sk-X mit unix_unvisited_vertices verknüpft, und unix_walk_scc() gruppiert sie in zwei verschiedene stark zusammenhängende Komponenten (SCCs):
unix_sk(sk-A)->vertex->scc_index = 2 (UNIX_VERTEX_INDEX_START) unix_sk(sk-X)->vertex->scc_index = 3
Sobald der GC abgeschlossen ist, wird unix_graph_grouped auf true gesetzt. Außerdem wird unix_graph_maybe_cyclic auf true gesetzt aufgrund der zyklischen Selbstreferenz von sk-X, was dazu führt, dass close() den GC auslöst.
Bei 3-b alloziert unix_add_edge() unix_sk(sk-B)->vertex und verknüpft es mit unix_unvisited_vertices.
unix_update_graph() wird bei 3-a. und 3-b. aufgerufen, aber weder unix_graph_grouped noch unix_graph_maybe_cyclic werden geändert, da weder der Listener von sk-B noch sk-C in der Übertragung (in-flight) sind.
3-c dekrementiert den Dateireferenzzähler (file refcnt) von sk-A auf 1.
Da unix_graph_grouped bei 3-d true ist, wird schließlich unix_walk_scc_fast() aufgerufen und iteriert über 3 Sockets: sk-A, sk-B und sk-X:
sk-A -> sk-B (-> sk-C) sk-X -> sk-X
Dies ist völlig in Ordnung. Alle von ihnen sind noch nicht close()t worden und sollten in verschiedene SCCs gruppiert werden.
Allerdings stuft unix_vertex_dead() fälschlicherweise ein, dass sk-A und sk-B in derselben SCC sind und sk-A tot ist.
unix_sk(sk-A)->scc_index == unix_sk(sk-B)->scc_index <-- Falsch! && file refcnt von sk-A == unix_sk(sk-A)->vertex->out_degree ^-- 1 In-Flight-Zähler für sk-B -> sk-A ist tot !?
Das Problem besteht darin, dass unix_add_edge() scc_index nicht initialisiert.
Phase 1) wird für Heap-Spraying verwendet, wodurch ein neu allozierter Vertex den Wert vertex->scc_index == 2 (UNIX_VERTEX_INDEX_START) annimmt, der von unix_walk_scc() bei 1-c gesetzt wurde.
Wir sollten den maximalen SCC-Index aus dem vorherigen unix_walk_scc()-Aufruf verfolgen und dem scc_index eines neuen Vertices max + 1 zuweisen.
Auf diese Weise können wir weiterhin den Algorithmus von Tarjan vermeiden, während wir Fehleinschätzungen verhindern.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.