CVE-2026-53341fhandle: fix UAF due to unlocked ->mnt_ns read in may_decode_fh()
Updated under an hour ago ()
Does this affect you?
It affects Linux and 1 other product. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
In the Linux kernel, the following vulnerability has been resolved: fhandle: fix UAF due to unlocked ->mnt_ns read in may_decode_fh() may_decode_fh() accesses mount::mnt_ns without holding any locks; that means the mount can concurrently be unmounted, and the mnt_namespace can concurrently be freed after an RCU grace period. This race can happens as follows, assuming that the mount point was created by open_tree(..., OPEN_TREE_CLONE): thread 1 thread 2 RCU __do_sys_open_by_handle_at do_handle_open handle_to_path may_decode_fh is_mounted [mount::mnt_ns access] [mount::mnt_ns access] __do_sys_close fput_close_sync __fput dissolve_on_fput umount_tree class_namespace_excl_destructor namespace_unlock free_mnt_ns mnt_ns_tree_remove call_rcu(mnt_ns_release_rcu) mnt_ns_release_rcu mnt_ns_release kfree [mnt_namespace::user_ns access] **UAF** Fix it by taking rcu_read_lock() around the mount::mnt_ns access, like in __prepend_path(). Additionally, document the semantics of mount::mnt_ns, and use WRITE_ONCE() for writers that can race with lockless readers. This bug is unreachable unless one of the following is set: - CONFIG_PREEMPTION - CONFIG_RCU_STRICT_GRACE_PERIOD because it requires an RCU grace period to happen during a syscall without an explicit preemption. This doesn't seem to have interesting security impact; worst-case, it could leak the result of an integer comparison to userspace (from the level check in cap_capable()), cause an endless loop, or crash the kernel by dereferencing an invalid address.
- CVSS
- 7.8 HIGH (v3.1, CNA)CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Analyzed
- Record last updated
- Oct 16, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | 620c266f394932e5decc4b34683a75dfc59dc2f4 builds before 15ea8dc42a02259d49dee38a658d40f60fcd75ed; from 620c266f394932e5decc4b34683a75dfc59dc2f4 before 32138633e51e6db59e474765cf93268c92b42888; from 620c266f394932e5decc4b34683a75dfc59dc2f4 before a8ed2c29fcfdac78db96c9da4e659c8a513f2a94; 620c266f394932e5decc4b34683a75dfc59dc2f4 builds before 40ab6644b99685755f740b872c00ef40d9aa870e | CNA record |
linux linux_kernel linux:linux_kernel | from 6.11 before 6.12.95; from 6.13 before 6.18.36; from 6.19 before 7.0.13; 7.1; 7.1; 7.1; 7.1; 7.1; and 1 more ranges | NVD |
References
- https://git.kernel.org/stable/c/15ea8dc42a02259d49dee38a658d40f60fcd75edpatch
- https://git.kernel.org/stable/c/32138633e51e6db59e474765cf93268c92b42888patch
- https://git.kernel.org/stable/c/a8ed2c29fcfdac78db96c9da4e659c8a513f2a94patch
- https://git.kernel.org/stable/c/40ab6644b99685755f740b872c00ef40d9aa870epatch
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.