Description
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.
Published: 2026-10-23
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Privilege Escalation and Information Disclosure via Mount Namespace Lock Bypass
Action: Immediate Patch
AI Analysis

Impact

The flaw arises when a mount that has a protected lock is propagated into a user namespace and the lock state is incorrectly transferred to the new mount. A namespace owner can then replace its locked /proc or root filesystem, unmount the original protected mount, and read or manipulate sensitive data. This bypass of normal mount locking rules allows a local attacker who can create a user namespace to gain unauthorized access and potentially elevate privileges.

Affected Systems

All Linux kernel releases that lack the fixes in commits d74d66aa708ccf2bc0b1e265a83fed0f2308d5c4 and f1f0c24ca701d7d3061c7f69f7450f1734c11745. Systems that enable mount namespaces with propagation, especially those exposing /proc or root mounts to child namespaces, are susceptible.

Risk and Exploitability

The vulnerability is local and does not require external network access. Because any user capable of creating a user namespace can exploit the flaw, the risk is high. The CVSS score is 7.8, the EPSS score is less than 1%, and the issue is not currently listed in the CISA KEV catalog, yet the possibility of privilege escalation and data exposure keeps the threat significant.

Generated by OpenCVE AI on October 29, 2026 at 22:47 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply a kernel update that includes the commits that correct MNT_LOCKED propagation behavior (d74d66aa708ccf2bc0b1e265a83fed0f2308d5c4 or f1f0c24ca701d7d3061c7f69f7450f1734c11745).
  • If immediate kernel upgrade is not possible, disable user namespace creation and mount propagation by setting `kernel.unprivileged_userns_clone=0` and removing the `user_allow_other` mount option, thereby preventing the exploitation vector.
  • After applying the patch or disabling namespaces, audit active mount namespaces to ensure no unlocked /proc or root mounts remain; use the `mountinfo` file or the `lsns` command to verify that all critical mounts retain the lock, ensuring that privilege boundaries are respected.

Generated by OpenCVE AI on October 29, 2026 at 22:47 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 29 Oct 2026 21:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-269
CWE-284

Thu, 29 Oct 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-281
References
Metrics threat_severity

None

 threat_severity

Moderate

Sat, 24 Oct 2026 19:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-269
CWE-284

Sat, 24 Oct 2026 17:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-272

Sat, 24 Oct 2026 14:15:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H'}

Fri, 23 Oct 2026 17:45:00 +0000

Type Values Removed Values Added
First Time appeared Linux linux
Vendors & Products Linux linux

Fri, 23 Oct 2026 15:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-272

Fri, 23 Oct 2026 12:45:00 +0000

Type Values Removed Values Added
Description 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.
Title namespace: keep the lock on a mount that a propagated copy is moved beneath
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-24T14:09:46.343Z

Reserved: 2026-09-25T10:25:14.383Z

Link: CVE-2026-98976

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-23T13:17:19.280

Modified: 2026-10-24T14:16:50.243

Link: CVE-2026-98976

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-10-23T00:00:00Z

Links: CVE-2026-98976 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-29T23:00:06Z

Weaknesses
  • CWE-281

    Improper Preservation of Permissions