CVE-2025-40214: af_unix: Initialise scc_index in unix_add_edge().
In multiple functions of garbage.c, there is a possible use after free due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
Other sources
In the Linux kernel, the following vulnerability has been resolved:
afunix: Initialise sccindex in unixaddedge().
Quang Le reported that the AFUNIX 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->sccindex = 3
Once GC completes, unixgraphgrouped is set to true. Also, unixgraphmaybecyclic 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 unixunvisitedvertices.
unixupdategraph() is called at 3-a. and 3-b., but neither unixgraphgrouped nor unixgraphmaybecyclic 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, unixwalksccfast() 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 sccindex.
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 sccindex.
This way, we can continue to avoid Tarjan's algorithm while preventing misjudgments.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.159 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.117 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.59 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.17.9 - Upgrade
Upgrade
android/:linux_kernel:to a version that resolves this vulnerability.Fixed in :2026-06-05
Event History
Frequently Asked Questions
What is the severity of CVE-2025-40214?
CVE-2025-40214 has been classified with a severity rating that indicates a potential security risk for affected versions of the Linux kernel.
How do I fix CVE-2025-40214?
To fix CVE-2025-40214, users should update to the latest stable version of the Linux kernel that includes the patch for this vulnerability.
Which versions of the Linux kernel are affected by CVE-2025-40214?
CVE-2025-40214 affects all versions of the Linux kernel prior to the inclusion of the patch addressing this vulnerability.
What type of vulnerability is CVE-2025-40214?
CVE-2025-40214 is a vulnerability related to the garbage collection process of the AF_UNIX socket implementation in the Linux kernel.
Who reported CVE-2025-40214?
CVE-2025-40214 was reported by researcher Quang Le, who provided a demonstration of the issue.