CVE-2026-98976

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug lets certain local users bypass protections that keep secret files hidden inside special containers or user accounts.

Exploitation: Local Privilege
Attacker needs: Low Privilege
Complexity: High
Impact: Privilege Gain
Component: OS kernel
Class: Privilege Escalation
Remediation: Upgrade
Effort: Medium
Patch risk: Medium

What it actually does

The vulnerability allows improper transfer of the MNT_LOCKED flag during attach_recursive_mnt with MOVE_MOUNT_BENEATH when a propagated mount lands beneath a locked cover, unlocking the covering mount and permitting subsequent unmount by a user-namespace owner.

Why it matters to the business

Local attackers can bypass mount protections that isolate sensitive data inside containers or user namespaces, potentially exposing secrets or enabling further privilege escalation on affected Linux systems.

How an attack unfolds

An attacker in a user namespace observes a host mount propagation that places a copy beneath its locked cover, causing the lock to transfer incorrectly; after the host unmounts the propagated mount, the attacker can unmount the now-unlocked cover and access the previously protected path.

How to fix it

Apply the upstream kernel commit that restricts MNT_LOCKED transfer to only mounts placed by the caller; rebuild and deploy updated kernels to all affected hosts and container hosts as soon as available.

How to confirm the fix worked

Confirm the fix by verifying the presence of the namespace mount lock logic change in the running kernel source or by reproducing the original propagation scenario and confirming the cover remains locked.

Typical attack path

Create or enter a user namespace with its own mount namespace derived from the host
Arrange a shared mount on the host that propagates into the namespace and receives a locked cover
Trigger a host mount operation that propagates a new mount beneath the locked cover
Observe the host unmount the propagated mount, leaving the cover unlocked
Perform umount on the cover path to reveal the underlying sensitive mount contents

How to detect it

Review system and audit logs for sequences of mount propagation followed by unexpected umount2 calls succeeding on previously locked paths; correlate with user-namespace creation events.

What your security team should do

Prioritize kernel updates on systems hosting untrusted workloads or user namespaces
Audit container runtime configurations that allow unprivileged user namespaces
Monitor for unusual mount/umount activity originating from user namespaces

The record

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.

Affected packages

Ecosystem	Package	Introduced	Fixed