EUVD-2026-108770
GHSA-38fm-jc3c-v2pm
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain local unprivileged account on host
-
DeliveryCreate user namespace receiving propagated locked cover mount
-
ExploitHost mount/unmount over covered path mis-transfers lock
-
ExecutionUnmount now-unlocked cover
-
ImpactRead underlying host-protected content
Vulnerability Assessment
| Exploitation Conditions | Requires: (1) local access with an unprivileged account; (2) a kernel/distro that permits unprivileged user-namespace creation (e.g. CONFIG_USER_NS with unprivileged userns enabled); (3) a mount-propagation layout in which the user namespace's copy of a host shared mount receives propagation and has a locked cover (MNT_LOCKED) over a sensitive mountpoint such as /proc or the namespace root; and (4) host-side mount followed by unmount over that covered path, which is what causes the lock to be mis-transferred and the cover to become unlocked. Limiting factors that reduce real-world exploitability: the vector is local only (AV:L), the race/propagation sequencing makes it high-complexity (AC:H), a valid local account is needed (PR:L), and hosts that disable unprivileged user namespaces or do not share mounts into user namespaces are not exposed. The only complete fix is updating to a kernel containing the referenced stable commits. |
| Impact | Signals point to a real but non-emergency local privilege/isolation flaw rather than a mass-exploitation threat. The CVSS 3.1 base score is 7.8 (HIGH), but the vector itself tempers that: AV:L means no remote reach, AC:H means the attacker must line up specific mount-propagation timing, and PR:L means a working local account is required; the severity is driven largely by S:C (scope change across the user-namespace boundary) plus C:H/I:H/A:H impact. EPSS is low at 0.20% (9th percentile), there is no CISA KEV listing, and no public exploit or PoC reference is present in the input - only the two kernel.org stable fix commits. These signals are consistent with each other (low real-world exploitation likelihood) and align with the vuln.today 'this_week' priority label, which is below act_now/emergency. The practical risk concentrates in multi-tenant and container hosts that permit unprivileged user namespaces, where the bug can expose host data otherwise hidden behind a locked cover mount. No SSVC decision string (automatable / technical-impact) is provided, and CWE is N/A, so those framework inputs are missing. Net: patch on a prompt, planned basis - especially on shared/container infrastructure - but this is not a drop-everything issue. |
| Exploit ScenarioDerived | On a multi-tenant Linux host that allows unprivileged user namespaces, a local user creates a namespace whose copy of a shared host mount receives propagation and carries a locked cover over a sensitive path (e.g. /proc or the namespace root). By relying on the host mounting and then unmounting something over that covered path, the MNT_LOCKED property is mis-transferred and the cover becomes unlocked, letting the user unmount it and read the underlying host secret. The trigger requires specific propagation setup and host-side mount activity (consistent with AC:H), and no public exploit code is identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 24, 2026
The Linux kernel's mount-namespace propagation code can strip the MNT_LOCKED protection from a locked mount that covers a sensitive path - such as a user namespace's /proc or its root - allowing a local user who controls a user namespace to unmount that cover and read content it was supposed to hide, as demonstrated by the propagation sequence in the upstream commit message. Affected are kernels built with user-namespace support where an unprivileged user can create user namespaces whose shared-mount copies receive propagation from the host and whose cover over a sensitive mountpoint carries MNT_LOCKED; hosts that disable unprivileged user namespaces or never share mounts into user namespaces are not exposed. The assessed severity is CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N (local, high complexity, scope-changing, high confidentiality impact), EPSS is 0.20% (9th percentile), and this is not a CISA KEV entry: no public exploit was identified at time of analysis.
RemediationAI
The complete fix is a kernel update containing the referenced stable commits; per EUVD the patched versions are 7.2.11 and 7.3, and the specific changes are f1f0c24ca701d7d3061c7f69f7450f1734c11745 and d74d66aa708ccf2bc0b1e265a83fed0f2308d5c4 in git.kernel.org's stable tree. Apply the vendor or distribution kernel that carries the equivalent patch rather than the upstream hashes where your distro backports, and treat the eight-character prefix identifier c62a4766937edec2962d52e583276b459b739f2d as the pre-fix baseline for comparison. If updating cannot be scheduled immediately, the exposure hinges on the prerequisites in the assessment: on hosts that do not need user namespaces for containers, sandboxes or unprivileged builds, disabling unprivileged user-namespace creation (kernel.unprivileged_userns_clone=0 on Debian-derived kernels, or user.max_user_namespaces=0) removes the attacker's ability to reach the flawed propagation path, at the cost of breaking rootless containers, browser and application sandboxes, and unprivileged build tooling. Restricting mount propagation so that shared mounts are not propagated into user namespaces reduces exposure for privileged service layouts, but it changes the intended mount topology and must be validated against the workloads relying on it. These are compensating controls only; the vendor's position is that updating is the only complete fix.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw lives in the mount-propagation machinery of the Linux VFS, specifically in attach_recursive_mnt() and its handling of MOVE_MOUNT_BENEATH when a mount is placed underneath another mount. MNT_LOCKED is the flag that marks a mount inside a less-privileged user namespace as un-unmountable, so that a locked clone of /proc or of the namespace root cannot be peeled away by that namespace's owner. When a propagated copy of a host mount lands beneath a locked cover, the code transferred the locked property from the top mount to the newly arrived mount beneath it, freeing the top mount of its lock; once the host unmounted again, the propagated copy disappeared and the covering mount was left unlocked on top of the still-sensitive mountpoint, so the namespace owner could umount2() it and read the previously hidden path. The fix only transfers locked state for mounts the caller itself placed, and marks propagated copies that land beneath a locked mount as locked too, so the bottom of the stack carries the lock every check expects while the top mount stays locked and keeps covering even if the propagated mount is later unmounted. No CWE identifier is assigned in the supplied data; the root cause class is a failure to preserve a security-relevant mount flag across a propagation-driven mount move. The trigger requires the specific shared-mount propagation layout described in the advisory - the host must mount over the covered path and then unmount - which is why the assessed vector rates the attack high-complexity (AC:H) despite being local (AV:L) with a low-privileged account (PR:L).
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
Local unprivileged user (AV:L/PR:L), high complexity from required mount-propagation and host mount/unmount timing (AC:H), S:C as disclosure crosses the user-namespace boundary to host data; main impact is confidentiality, limited integrity from cover replacement, no availability loss.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
3DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
namespace: keep the lock on a mount that a propagated copy is moved beneath
attach_recursive_mnt() transfers MNT_LOCKED from the top mount to the mount that is moved beneath it with MOVE_MOUNT_BENEATH. This allows the owner of a user namespace to replace its locked /proc or its root. The mount beneath takes on the job of covering the underlying mountpoint allowing the top mount to be unmounted.
Consider two mount namespaces:
(H) The host H has a shared mount P with a secret in P/d (Z) Z is a user namespace made from M. Its copy of P receives propagation from the host's P and its copy of M's cover on P/d is locked Z's owner must not get to see P/d.
Now (H) mounts X on P/d. This propagates into (Z). The copy of X lands beneath (Z)'s locked cover. The locked property is transfered from (Z)'s cover to the copy of X propagated beneath it. The cover is now unlocked.
Now (H) unmounts X again. The copy of X in (Z) gets unmounted and the covering mount is left unlocked on top of P/d. (Z) can now unmount it:
Z: umount2(P/d) = EINVAL /* the cover is locked */ H: mount X on P/d, umount X /* both propagate into Z /* Z: umount2(P/d) = 0 /* the cover is now unlocked */ Z: read P/d/secret = "covered-by-root" /* secret revealed */
So only transfer the locked property to the mount beneath for mounts the caller has placed. A propagated copy that lands beneath a locked mount is locked as well so that the mount at the bottom of the stack carries a lock the way every check expects. The mount on top of it remains locked to ensure that it keeps covering even if the propagated mount is unmounted again.
Executive ViewAI
A high-severity vulnerability in the Linux kernel (CVE-2026-98976) allows a local unprivileged user to potentially bypass mount protections and access sensitive data on systems that permit unprivileged user namespaces and share mounts. This could lead to unauthorized disclosure of confidential information, impacting organizations relying on such kernel configurations for multi-tenant isolation.
No vendor-released patch identified at time of analysis. Interim mitigations include disabling unprivileged user namespaces (e.g., via sysctl kernel.unprivileged_userns_clone=0) and preventing mount propagation into user namespaces (e.g., using mount options like MS_SLAVE or MS_PRIVATE).
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB