CVE-2025-40214

Enriched by CISA
 

In 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.
https://nvd.nist.gov/vuln/detail/CVE-2025-40214

Categories

No category defined

References


 

AFFECTED (from MITRE)

Vendor Product Versions
Linux Linux
  • adfb68b39b39767d6bfb53e48c4f19c183765686 < 20003fbb9174121b27bd1da6ebe61542ac4c327d [affected]
  • d23802221f6755e104606864067c71af8cdb6788 < 4cd8d755c7d4f515dd9abf483316aca2f1b7b0f3 [affected]
  • ad081928a8b0f57f269df999a28087fce6f2b6ce < db81ad20fd8aef7cc7d536c52ee5ea4c1f979128 [affected]
  • ad081928a8b0f57f269df999a28087fce6f2b6ce < 1aa7e40ee850c9053e769957ce6541173891204d [affected]
  • ad081928a8b0f57f269df999a28087fce6f2b6ce < 60e6489f8e3b086bd1130ad4450a2c112e863791 [affected]
Linux Linux
  • 6.10 [affected]
  • < 6.10 [unaffected]
  • 6.1.159 ≤ 6.1.* [unaffected]
  • 6.6.117 ≤ 6.6.* [unaffected]
  • 6.12.59 ≤ 6.12.* [unaffected]
  • 6.17.9 ≤ 6.17.* [unaffected]
  • 6.18 ≤ * [unaffected]
© 2022 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation.

CPE

cpe start end
Configuration 1
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* >= 6.1.141 < 6.1.159
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* >= 6.6.93 < 6.6.117
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* >= 6.10 < 6.12.59
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* >= 6.10 < 6.17.9
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* >= 6.10 < 6.18

REMEDIATION


EXPLOITS

Exploit-db.com

id description date
No known exploits

POC Github

Url
No known exploits

Other Nist (github, ...)

Url
No known exploits

CAPEC

Common Attack Pattern Enumerations and Classifications

id description severity
No entry