Skip to main content

Linux Kernel EUVDEUVD-2026-40975

| CVE-2026-53341 HIGH
Use After Free (CWE-416)
2026-07-01 Linux GHSA-r4cc-8gxc-2cxh
7.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
5.3 MEDIUM

Local-only and requires winning a tight RCU race (AV:L/AC:H) via user-namespace mount cloning (PR:L); worst case is a kernel crash (A:H) with a minor capability-comparison leak (C:L) and no integrity impact.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:H
4.0 AV:L/AC:H/AT:N/PR:L/UI:N/VC:L/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
4.7 MEDIUM
AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:H
Red Hat
7.0 MEDIUM
qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 18, 2026 - 08:23 vuln.today
CVSS changed
Jul 18, 2026 - 08:22 NVD
7.8 (HIGH)
Patch available
Jul 01, 2026 - 15:16 EUVD
CVE Published
Jul 01, 2026 - 13:32 cve.org
UNKNOWN (no severity yet)
CVE Published
Jul 01, 2026 - 13:32 cve.org
HIGH 7.8

DescriptionCVE.org

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.

AnalysisAI

Use-after-free race condition in the Linux kernel's fhandle subsystem, where may_decode_fh() reads mount::mnt_ns without RCU protection, allowing a concurrently-unmounted mount namespace to be freed and dereferenced during an open_by_handle_at() call. The affected code path is reachable only when the mount was created via open_tree(OPEN_TREE_CLONE) and the kernel is built with CONFIG_PREEMPTION or CONFIG_RCU_STRICT_GRACE_PERIOD. Per the upstream fix note, real-world impact is limited to a kernel crash (DoS), an endless loop, or a minor information leak (the result of a capability level comparison); there is no public exploit identified at time of analysis and EPSS probability is very low at 0.15%.

Technical ContextAI

The bug lives in Linux VFS file-handle decoding (fs/fhandle.c, may_decode_fh()), which validates whether a caller may resolve an opaque file handle back to a path via open_by_handle_at(). It calls is_mounted() and reads mount::mnt_ns to check namespace ownership, but does so without rcu_read_lock() or the namespace_sem lock. Because detached mounts created by open_tree(OPEN_TREE_CLONE) are torn down asynchronously in __fput -> dissolve_on_fput -> umount_tree, the mnt_namespace can be freed by call_rcu(mnt_ns_release_rcu) after an RCU grace period, producing a classic use-after-free (CWE-416) rooted in a data race / concurrent unlocked read (CWE-362). The listed CWE is N/A in the feed, but the crash pattern and the fix (wrapping the access in rcu_read_lock() and adding WRITE_ONCE() for racing writers, mirroring __prepend_path()) confirm a lockless-read UAF. The reachability gate on CONFIG_PREEMPTION / CONFIG_RCU_STRICT_GRACE_PERIOD exists because a grace period must elapse mid-syscall without an explicit preemption point.

RemediationAI

Vendor-released patch: update to Linux kernel 6.18.36, 7.0.13, or 7.1 (or the equivalent backported build from your distribution) which wraps the mount::mnt_ns access in rcu_read_lock() and adds WRITE_ONCE() for racing writers; the fix commits are 32138633e51e6db59e474765cf93268c92b42888, a8ed2c29fcfdac78db96c9da4e659c8a513f2a94 and 40ab6644b99685755f740b872c00ef40d9aa870e (https://git.kernel.org/stable/c/32138633e51e6db59e474765cf93268c92b42888). Apply this through your distribution's normal kernel update and reboot. If patching must be deferred, the practical compensating control is to restrict the primitives the race depends on: because it is gated on unprivileged mount cloning, disabling unprivileged user namespaces (sysctl kernel.unprivileged_userns_clone=0, or user.max_user_namespaces=0) prevents unprivileged callers from reaching open_tree(OPEN_TREE_CLONE) and open_by_handle_at() with CAP_DAC_READ_SEARCH - at the cost of breaking rootless containers and sandboxes that rely on user namespaces. Kernels not built with CONFIG_PREEMPTION or CONFIG_RCU_STRICT_GRACE_PERIOD are not reachable, but changing that build option purely for mitigation is not recommended given its broad latency/behavior side effects.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

EUVD-2026-40975 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy