CVE-2025-40214
- Source
- https://nvd.nist.gov/vuln/detail/CVE-2025-40214
- Import Source
- https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2025-40214.json
- JSON Data
- https://api.test.osv.dev/v1/vulns/CVE-2025-40214
- Aliases
- Downstream
- Published
- 2025-12-04T12:38:31.601Z
- Modified
- 2026-01-14T18:56:56.911067Z
- Summary
- af_unix: Initialise scc_index in unix_add_edge().
- Details
-
In the Linux kernel, the following vulnerability has been resolved:
afunix: Initialise sccindex in unixaddedge().
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 unixunvisitedvertices, and unixwalkscc() groups them into two different SCCs:
unixsk(sk-A)->vertex->sccindex = 2 (UNIXVERTEXINDEXSTART) unixsk(sk-X)->vertex->scc_index = 3
Once GC completes, unixgraphgrouped is set to true. Also, unixgraphmaybe_cyclic is set to true due to sk-X's cyclic self-reference, which makes close() trigger GC.
At 3-b, unixaddedge() allocates unixsk(sk-B)->vertex and links it to unixunvisited_vertices.
unixupdategraph() is called at 3-a. and 3-b., but neither unixgraphgrouped nor unixgraphmaybe_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 unixgraphgrouped is true at 3-d, unixwalkscc_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, unixvertexdead() misjudges that sk-A and sk-B are in the same SCC and sk-A is dead.
unixsk(sk-A)->sccindex == unixsk(sk-B)->sccindex <-- Wrong! && sk-A's file refcnt == unixsk(sk-A)->vertex->outdegree ^-- 1 in-flight count for sk-B -> sk-A is dead !?
The problem is that unixaddedge() does not initialise scc_index.
Stage 1) is used for heap spraying, making a newly allocated vertex have vertex->sccindex == 2 (UNIXVERTEXINDEXSTART) set by unixwalkscc() at 1-c.
Let's track the max SCC index from the previous unixwalkscc() 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.
- Database specific
{ "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/40xxx/CVE-2025-40214.json", "cna_assigner": "Linux" }- References
-
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- https://git.kernel.org/stable/c/1aa7e40ee850c9053e769957ce6541173891204d
- https://git.kernel.org/stable/c/20003fbb9174121b27bd1da6ebe61542ac4c327d
- https://git.kernel.org/stable/c/4cd8d755c7d4f515dd9abf483316aca2f1b7b0f3
- https://git.kernel.org/stable/c/60e6489f8e3b086bd1130ad4450a2c112e863791
- https://git.kernel.org/stable/c/db81ad20fd8aef7cc7d536c52ee5ea4c1f979128
- https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/40xxx/CVE-2025-40214.json
- https://nvd.nist.gov/vuln/detail/CVE-2025-40214
Affected packages
Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Affected ranges
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedadfb68b39b39767d6bfb53e48c4f19c183765686Fixed20003fbb9174121b27bd1da6ebe61542ac4c327d
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedd23802221f6755e104606864067c71af8cdb6788Fixed4cd8d755c7d4f515dd9abf483316aca2f1b7b0f3
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedad081928a8b0f57f269df999a28087fce6f2b6ceFixeddb81ad20fd8aef7cc7d536c52ee5ea4c1f979128Fixed1aa7e40ee850c9053e769957ce6541173891204dFixed60e6489f8e3b086bd1130ad4450a2c112e863791
Affected versions
v6.*
Linux / Kernel
Package
- Name
- Kernel