CVE-2026-53341

What it actually does

This is a Linux kernel use-after-free race in file-handle decoding. The vulnerable path reads mount::mnt_ns in may_decode_fh() without the required RCU protection while another thread can unmount a cloned mount and free the associated mnt_namespace. If the race is won, subsequent access to the freed namespace can dereference invalid memory. Practical outcomes are expected to be limited to a kernel crash, hang, or minor information leakage from an integer comparison result, although the CVSS vector reflects the general risk class of a local kernel memory-safety flaw. The issue is only reachable on kernels built with CONFIG_PREEMPTION or CONFIG_RCU_STRICT_GRACE_PERIOD because the race requires an RCU grace period to complete during the syscall path.

Why it matters to the business

Successful exploitation requires local code execution or a local account, but it can affect system availability by crashing or hanging Linux hosts. On shared Linux systems, container hosts, developer workstations, CI runners, bastion hosts, and multi-user servers, a low-privileged user or compromised workload could potentially trigger a denial of service. There is no indication of known exploitation, CISA KEV listing, ransomware use, or mature public exploit activity, and the EPSS score is very low, so urgency is lower than for internet-facing remote code execution; however, kernel fixes should still be prioritized where untrusted local users or containers are present.

How an attack unfolds

An attacker first obtains the ability to run local code on an affected Linux system. They then create or manipulate a cloned mount, for example through mount-related file-handle operations, and race two execution paths: one path invokes open_by_handle_at() so the kernel enters do_handle_open(), handle_to_path(), and may_decode_fh(); the other path closes or tears down the cloned mount so the mount namespace can be released after an RCU grace period. On vulnerable kernels, may_decode_fh() can read mount::mnt_ns without holding rcu_read_lock(), allowing the namespace object to be freed and later referenced. If the timing is successful, the kernel may dereference freed memory, leading to a crash, lockup, or limited leakage of state back to userspace. The upstream fix wraps the mount namespace access in RCU read-side protection and uses WRITE_ONCE() for racing writers.

How to fix it

Apply a vendor kernel update that includes the upstream fhandle fix for may_decode_fh(), specifically the change that protects mount::mnt_ns access with rcu_read_lock() and uses WRITE_ONCE() for racing writers. Because no exact fixed package versions were provided, use the security advisory and package metadata from the relevant Linux distribution or kernel vendor to identify the fixed kernel build. After installation, reboot into the updated kernel; installing the package alone is not sufficient if the system continues running the old kernel. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, disabling or constraining user namespaces where operationally feasible, enforcing container isolation controls, and monitoring for kernel oops/panic events associated with file-handle and mount namespace activity. These mitigations reduce exploitability but do not replace patching.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, has been updated to a vendor build containing the fix. Validate with uname -r, distribution package tools, and the vendor advisory or changelog for the fhandle/may_decode_fh() fix. Check the kernel configuration for CONFIG_PREEMPTION or CONFIG_RCU_STRICT_GRACE_PERIOD to understand reachability. Review recent boot history to ensure hosts were rebooted after patch deployment. Where source-level validation is possible, confirm may_decode_fh() protects mount::mnt_ns access with rcu_read_lock()/rcu_read_unlock() and that relevant mount namespace writers use WRITE_ONCE(). Also verify that local hardening controls for untrusted users and containers remain in place until all affected kernels are remediated.

Typical attack path

1. Gain local code execution on an affected Linux host, such as through a local shell, compromised service account, container workload, or untrusted user session.
2. Identify that the kernel is built with CONFIG_PREEMPTION or CONFIG_RCU_STRICT_GRACE_PERIOD and includes the vulnerable file-handle decoding code path.
3. Create or use a cloned mount, such as one produced through open_tree(..., OPEN_TREE_CLONE).
4. Invoke open_by_handle_at() repeatedly to drive execution into do_handle_open(), handle_to_path(), and may_decode_fh().
5. Concurrently close, unmount, or otherwise tear down the cloned mount so the associated mnt_namespace can be freed after an RCU grace period.
6. Win the race so may_decode_fh() observes or uses a freed mnt_namespace pointer.
7. Cause a kernel crash, hang, or limited information exposure; reliable privilege escalation is not established from the available description.

How to detect it

Detection should focus on signs of prior local exploitation attempts and resulting kernel instability. Review kernel logs from journald, syslog, dmesg, crash dump tooling, and centralized EDR telemetry for oops, panic, general protection fault, use-after-free, RCU, mount namespace, and file-handle decoding messages. Pay particular attention to crashes with stack traces containing may_decode_fh(), handle_to_path(), do_handle_open(), open_by_handle_at(), dissolve_on_fput(), umount_tree(), namespace_unlock(), free_mnt_ns(), or mnt_ns_release_rcu(). Correlate kernel faults with bursts of local processes invoking open_by_handle_at(), open_tree(), close(), and unmount-related syscalls, especially from untrusted user sessions, containers, fuzzing-like processes, or recently compromised services. If auditd, eBPF, syscall tracing, or EDR telemetry is available, search for repeated open_by_handle_at and open_tree activity followed by kernel warnings, host reboots, watchdog resets, or crash dumps. Absence of these artifacts does not prove non-exploitation because a successful denial-of-service attempt may leave only a panic or abrupt reboot record.

• may_decode_fh
• handle_to_path
• do_handle_open
• open_by_handle_at
• open_tree
• OPEN_TREE_CLONE
• dissolve_on_fput
• umount_tree
• namespace_unlock
• free_mnt_ns
• mnt_ns_release_rcu
• mnt_ns_release
• mount::mnt_ns
• mnt_namespace::user_ns
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel paging request
• general protection fault
• kernel BUG
• Kernel panic
• Oops:
• RCU grace period
• use-after-free
• KASAN: use-after-free
• cap_capable

What your security team should do

• Inventory Linux systems running affected kernel versions, prioritizing multi-user systems, container hosts, CI/CD runners, developer platforms, and systems allowing untrusted local code execution.
• Patch affected systems using vendor-provided kernel updates and reboot them into the fixed kernel.
• Treat systems with CONFIG_PREEMPTION or CONFIG_RCU_STRICT_GRACE_PERIOD enabled as reachable and prioritize them ahead of kernels where the bug is not reachable.
• Temporarily reduce local attack surface by limiting untrusted shell access, tightening container privileges, and restricting namespace-related capabilities where feasible.
• Monitor kernel logs for oops, panic, RCU, mount namespace, open_by_handle_at, and fhandle-related crash artifacts that may indicate attempted exploitation or stability impact.
• Because there is no KEV listing, no known ransomware association, very low EPSS, and no reported exploit maturity, schedule remediation according to kernel patch cycles unless the environment permits untrusted local code execution, in which case expedite.