Look up another CVE · open CVE-2026-53341 in the interactive tracker
CVE-2026-53341
fhandle: fix UAF due to unlocked ->mnt_ns read in may_decode_fh()
Published 2026-07-01 (4 months ago) by the Linux kernel CNA. Subsystem fs. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-53341 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | fixedDSA-6381-1 · 2026-07-05 · text | 6.12.95-1 | Update the kernel and reboot. DSA-6381-1 shipped the fix on 2026-07-05, in 6.12.95-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
fs/fhandle.c
fs/mount.h
fs/namespace.c
- What this is
- FILESYSTEMS [EXPORTFS]MAINTAINERS section matched on fs/fhandle.c · linux-fsdevel@vger.kernel.org · Supported
Check it on the machine
grep -w CONFIG_FHANDLE /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switch
- CONFIG_FHANDLE
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-01 (4 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.13%, higher than 2.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- fs
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.11 | 6.12.95 | 15ea8dc42a02 |
| 6.11 | 6.18.36 | 32138633e51e |
| 6.11 | 7.0.13 | a8ed2c29fcfd |
| 6.11 | 7.1 | 40ab6644b996 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DSA-6381-1 | 2026-07-05 | trixie 6.12.95-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The vulnerable code is reached through local syscalls, primarily `open_by_handle_at()` racing with close/fput of a mount file created by `open_tree(..., OPEN_TREE_CLONE)`. There is no network or adjacent attack path.
- AC:LAttack complexity, low
- The attacker can control both sides of the race by running concurrent local threads that call `open_by_handle_at()` and close the cloned mount file. Although the bug requires preemption or strict RCU grace periods, those are reasonable kernel configurations and the race is attacker-driven.
- PR:LPrivileges required, low
- The path requires namespace-relative capabilities such as `CAP_SYS_ADMIN` and `CAP_DAC_READ_SEARCH`, which an unprivileged local user can obtain inside a user namespace on systems where unprivileged user namespaces are enabled. It does not require real init-namespace root.
- UI:NUser interaction, none
- No victim action is required; the attacker directly invokes the relevant syscalls and controls the racing threads. The mount clone, handle input, and close operation are all attacker initiated.
- S:UScope, unchanged
- The vulnerability affects kernel VFS/mount namespace state within the same security authority. It is a local kernel memory-safety issue, not a VM escape or cross-scope boundary bypass.
- C:HConfidentiality impact, high
- The bug is a kernel use-after-free of `struct mnt_namespace`, followed by dereferencing reclaimed memory through `mnt_ns->user_ns` and capability-walk fields. Per the higher-severity rule for kernel UAFs, this is scored as high confidentiality impact.
- I:HIntegrity impact, high
- The immediate operation is a stale read in an authorization check, but reclaimed kernel heap contents can influence capability-check control flow and UAFs are treated as potentially exploitable memory corruption. Under the required uncertainty rule, integrity impact is high.
- A:HAvailability impact, high
- The stale `mnt_namespace` dereference can crash the kernel, loop indefinitely, or otherwise destabilize the system. A local attacker can repeatedly trigger the race, so availability impact is high.