CVE-2025-40271

fs/proc: fix uaf in proc_readdir_de()

HIGH
7.8
CVSS Score
Published: December 6, 2025 at 09:50 PM UTC
Updated: October 15, 2026 at 07:10 PM UTC
2 products affected across 2 vendorsLinux KernelRUGGEDCOM RST2428P Firmware

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.8
Exploit prediction
EPSS 0.5%
SSVC
No known exploit

Description

In the Linux kernel, the following vulnerability has been resolved: fs/proc: fix uaf in proc_readdir_de() Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access. We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows: 1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3; 2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab; 3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access. CPU 0 | CPU 1 ------------------------------------------------------------------------- traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF | rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2)

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

3.19710585d4922fd315f2cada8fbe550ae8ed23e994
Vendor states this is fixed in 03de7ff197a3d0e17d0d5c58fdac99a63cba8110 (fixed)
Vendor states this is fixed in 1d1596d68a6f11d28f677eedf6cf5b17dbfeb491 (fixed)
Vendor states this is fixed in 4cba73c4c89219beef7685a47374bf88b1022369 (fixed)
Vendor states this is fixed in 623bb26127fb581a741e880e1e1a47d79aecb6f8 (fixed)
Vendor states this is fixed in 67272c11f379d9aa5e0f6b16286b9d89b3f76046 (fixed)
Vendor states this is fixed in 6f2482745e510ae1dacc9b090194b9c5f918d774 (fixed)
Vendor states this is fixed in 895b4c0c79b092d732544011c3cecaf7322c36a1 (fixed)
Vendor states this is fixed in c81d0385500446efe48c305bbb83d47f2ae23a50 (fixed)
Vendor states this is fixed in 3.19 (unaffected)
Vendor states this is fixed in 5.10.247 (unaffected)
Vendor states this is fixed in 5.15.197 (unaffected)
Vendor states this is fixed in 5.4.302 (unaffected)
Vendor states this is fixed in 6.1.159 (unaffected)
Vendor states this is fixed in 6.12.59 (unaffected)
Vendor states this is fixed in 6.17.9 (unaffected)
Vendor states this is fixed in 6.18 (unaffected)
Vendor states this is fixed in 6.6.117 (unaffected)
v < V4.0
Affected range stops below V4.0, so it looks safe — our inference, not a vendor statement

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

SSVC — Action Prioritization

SSVCNo known exploitNot automatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

7.8HIGHLinux
Vector?

Quick Info

StatusDEFERRED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card