CVE-2025-40214

Source
https://cve.org/CVERecord?id=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
Downstream
Related
Published
2025-12-04T12:38:31.601Z
Modified
2026-03-12T02:16:56.775148Z
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
{
    "cna_assigner": "Linux",
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/40xxx/CVE-2025-40214.json"
}
References

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
Introduced
adfb68b39b39767d6bfb53e48c4f19c183765686
Fixed
20003fbb9174121b27bd1da6ebe61542ac4c327d
Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
d23802221f6755e104606864067c71af8cdb6788
Fixed
4cd8d755c7d4f515dd9abf483316aca2f1b7b0f3
Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
ad081928a8b0f57f269df999a28087fce6f2b6ce
Fixed
db81ad20fd8aef7cc7d536c52ee5ea4c1f979128
Fixed
1aa7e40ee850c9053e769957ce6541173891204d
Fixed
60e6489f8e3b086bd1130ad4450a2c112e863791

Database specific

source
"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2025-40214.json"

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.1.159
Type
ECOSYSTEM
Events
Introduced
6.2.0
Fixed
6.6.117
Type
ECOSYSTEM
Events
Introduced
6.7.0
Fixed
6.12.59
Type
ECOSYSTEM
Events
Introduced
6.10.0
Fixed
6.17.9

Database specific

source
"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2025-40214.json"