af_unix: Initialise scc_index in unix_add_edge().

MITRE NVD CVE.ORG JSON API Print: PDF PDF

Summary

CVECVE-2025-40214
StatePUBLISHED
AssignerLinux
Source PriorityCVE Program / NVD first with legacy fallback
Published2025-12-04 13:15:48 UTC
Updated2026-06-12 10:16:20 UTC
DescriptionIn the Linux kernel, the following vulnerability has been resolved: af_unix: Initialise scc_index in unix_add_edge(). Quang Le reported that the AF_UNIX GC could garbage-collect a receive queue of an alive in-flight socket, with a nice repro. The repro consists of three stages. 1) 1-a. Create a single cyclic reference with many sockets 1-b. close() all sockets 1-c. Trigger GC 2) 2-a. Pass sk-A to an embryo sk-B 2-b. Pass sk-X to sk-X 2-c. Trigger GC 3) 3-a. accept() the embryo sk-B 3-b. Pass sk-B to sk-C 3-c. close() the in-flight sk-A 3-d. Trigger GC As of 2-c, sk-A and sk-X are linked to unix_unvisited_vertices, and unix_walk_scc() groups them into two different SCCs: unix_sk(sk-A)->vertex->scc_index = 2 (UNIX_VERTEX_INDEX_START) unix_sk(sk-X)->vertex->scc_index = 3 Once GC completes, unix_graph_grouped is set to true. Also, unix_graph_maybe_cyclic is set to true due to sk-X's cyclic self-reference, which makes close() trigger GC. At 3-b, unix_add_edge() allocates unix_sk(sk-B)->vertex and links it to unix_unvisited_vertices. unix_update_graph() is called at 3-a. and 3-b., but neither unix_graph_grouped nor unix_graph_maybe_cyclic is changed because both sk-B's listener and sk-C are not in-flight. 3-c decrements sk-A's file refcnt to 1. Since unix_graph_grouped is true at 3-d, unix_walk_scc_fast() is finally called and iterates 3 sockets sk-A, sk-B, and sk-X: sk-A -> sk-B (-> sk-C) sk-X -> sk-X This is totally fine. All of them are not yet close()d and should be grouped into different SCCs. However, unix_vertex_dead() misjudges that sk-A and sk-B are in the same SCC and sk-A is dead. unix_sk(sk-A)->scc_index == unix_sk(sk-B)->scc_index <-- Wrong! && sk-A's file refcnt == unix_sk(sk-A)->vertex->out_degree ^-- 1 in-flight count for sk-B -> sk-A is dead !? The problem is that unix_add_edge() does not initialise scc_index. Stage 1) is used for heap spraying, making a newly allocated vertex have vertex->scc_index == 2 (UNIX_VERTEX_INDEX_START) set by unix_walk_scc() at 1-c. Let's track the max SCC index from the previous unix_walk_scc() call and assign the max + 1 to a new vertex's scc_index. This way, we can continue to avoid Tarjan's algorithm while preventing misjudgments.

Risk And Classification

EPSS: 0.001640000 probability, percentile 0.059430000 (date 2026-06-18)

Vendor Declared Affected Products

SourceVendorProductVersionPlatforms
CNA Linux Linux affected adfb68b39b39767d6bfb53e48c4f19c183765686 20003fbb9174121b27bd1da6ebe61542ac4c327d git Not specified
CNA Linux Linux affected d23802221f6755e104606864067c71af8cdb6788 4cd8d755c7d4f515dd9abf483316aca2f1b7b0f3 git Not specified
CNA Linux Linux affected ad081928a8b0f57f269df999a28087fce6f2b6ce db81ad20fd8aef7cc7d536c52ee5ea4c1f979128 git Not specified
CNA Linux Linux affected ad081928a8b0f57f269df999a28087fce6f2b6ce 1aa7e40ee850c9053e769957ce6541173891204d git Not specified
CNA Linux Linux affected ad081928a8b0f57f269df999a28087fce6f2b6ce 60e6489f8e3b086bd1130ad4450a2c112e863791 git Not specified
CNA Linux Linux affected 6.1.141 6.1.159 semver Not specified
CNA Linux Linux affected 6.6.93 6.6.117 semver Not specified
CNA Linux Linux affected 6.10 Not specified
CNA Linux Linux unaffected 6.10 semver Not specified
CNA Linux Linux unaffected 6.1.159 6.1.* semver Not specified
CNA Linux Linux unaffected 6.6.117 6.6.* semver Not specified
CNA Linux Linux unaffected 6.12.59 6.12.* semver Not specified
CNA Linux Linux unaffected 6.17.9 6.17.* semver Not specified
CNA Linux Linux unaffected 6.18 * original_commit_for_fix Not specified
ADP Siemens RUGGEDCOM RST2428P affected V4.0 custom Not specified

References

ReferenceSourceLinkTags
git.kernel.org/stable/c/4cd8d755c7d4f515dd9abf483316aca2f1b7b0f3 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/1aa7e40ee850c9053e769957ce6541173891204d 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/20003fbb9174121b27bd1da6ebe61542ac4c327d 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
cert-portal.siemens.com/productcert/html/ssa-253495.html 0b142b55-0307-4c5a-b3c9-f314f3fb7c5e cert-portal.siemens.com
git.kernel.org/stable/c/60e6489f8e3b086bd1130ad4450a2c112e863791 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/db81ad20fd8aef7cc7d536c52ee5ea4c1f979128 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
mohandacherir.github.io/Qdiv7/posts/unix_new_gc 416baaa9-dc9f-4396-8d5f-8c081fb06d67 mohandacherir.github.io
CVE Program record CVE.ORG www.cve.org canonical
NVD vulnerability detail NVD nvd.nist.gov canonical, analysis
© CVE.report 2026 |

Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties, implied or otherwise, with regard to this information or its use. Any use of this information is at the user's risk. It is the responsibility of user to evaluate the accuracy, completeness or usefulness of any information, opinion, advice or other content. EACH USER WILL BE SOLELY RESPONSIBLE FOR ANY consequences of his or her direct or indirect use of this web site. ALL WARRANTIES OF ANY KIND ARE EXPRESSLY DISCLAIMED. This site will NOT BE LIABLE FOR ANY DIRECT, INDIRECT or any other kind of loss.

CVE, CWE, and OVAL are registred trademarks of The MITRE Corporation and the authoritative source of CVE content is MITRE's CVE web site. This site includes MITRE data granted under the following license.

Free CVE JSON API cve.report/api

CVE.report and Source URL Uptime Status status.cve.report