CVE-2026-98978 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
namespace: never expire a locked mount
Locked mounts are special. They protect the underlying files and directories from being revealed. do_umount() refuses to unmount locked mounts but shrink_submounts() doesn't.
A shrinkable mount can become locked once the owner of a user namespace puts it beneath a locked mount with MOVE_MOUNT_BENEATH. The locked property now moves to the mount at the bottom making it possible to unmount the top mount.
So umount() of an unlocked ancestor now expires the bottom mount first and the covered directory is revealed:
move_mount(c -> x/hidden, MOVE_MOUNT_BENEATH) = 0 the cover after the lock moved: umount2(x/hidden) = 0 the holder of the lock: umount2(x/hidden) = EINVAL the root of the copy, busy: umount2(x) = EBUSY reads x/hidden/secret: "covered-by-root"
So leave a locked mount alone as it dies together with its parent. A plain umount() of an unlocked mount with a locked one below it is EBUSY from now on. It's the same for any other locked child. A lazy umount still takes the whole tree.
mark_mounts_for_expiry() never sees a locked mount. lock_mnt_tree() leaves a mount on an expiry list alone and nothing else puts a locked one on such a list. Add an assert for this.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel contains a logic flaw in the handling of mounted filesystem namespaces, specifically concerning the interaction between locked mounts and unmount operations initiated by user namespace owners. Locked mounts are designed to protect underlying files and directories from being revealed or accessed by unauthorized entities, serving as a critical security boundary within containerized environments where isolation is paramount. The vulnerability arises because while the do_umount function correctly refuses to directly unmount locked mounts, the shrink_submounts routine does not enforce this restriction when processing child mounts during namespace cleanup operations. This discrepancy creates a path for privilege escalation or information disclosure by allowing an attacker to bypass mount locking protections through indirect unmounting mechanisms.
The core technical flaw occurs when a user with ownership of a specific user namespace moves a mount beneath another mount using the MOVE_MOUNT_BENEATH operation, thereby creating a locked state on the lower-level mount. In this configuration, the upper mount acts as a cover that hides sensitive data located in the hidden directory structure below it. Although the system correctly prevents direct unmounting of the locked bottom mount by returning an error code such as EINVAL to the lock holder, and also returns EBUSY when attempting to unmount busy root copies, there was no protection against unmounting unlocked ancestor mounts that sit above these locked structures. When a user performs a standard umount operation on an unlocked parent directory, the kernel's internal expiration logic incorrectly processes the child mount first rather than preserving its locked status relative to its parent context.
This sequence of events leads to a significant security impact where the covered directory is unexpectedly revealed to users who should not have access to it. By exploiting this behavior, an attacker can effectively strip away the protective layer provided by the mounted filesystem hierarchy without triggering the expected permission checks associated with direct unmount attempts on locked mounts. The result is that sensitive information stored in directories intended to remain hidden becomes accessible, violating the isolation guarantees promised by Linux namespaces and potentially exposing confidential data or system configurations to processes running under less privileged user contexts.
To address this issue, developers have implemented a fix ensuring that locked mounts are never expired independently of their parent mount structures. The updated logic dictates that if an unmount operation targets an unlocked ancestor containing locked children, the entire tree is treated as busy and the operation fails with EBUSY rather than proceeding to expire or remove any components. This approach maintains the integrity of the lock hierarchy by ensuring that a locked mount dies together with its parent, preventing partial exposure scenarios. Additionally, assertions have been added within mark_mounts_for_expiry and related functions to verify programmatically that no locked mounts are ever placed on expiry lists, providing an additional layer of defense against future regressions in this logic path.
From a vulnerability classification perspective, this issue aligns with CWE-20 Improper Input Validation as the kernel failed to properly validate the state of child mounts before processing unmount requests for their ancestors. It also relates to CWE-732 Incorrect Permission Assignment for Critical Resource since the access controls governing mount visibility were circumvented through a logic error rather than a direct permission bypass. In terms of adversarial tactics, this vulnerability could be leveraged within ATT&CK technique T1083 File and Directory Discovery if an attacker seeks to locate sensitive files hidden behind mounted overlays, or potentially contribute to lateral movement scenarios in containerized environments where namespace isolation is relied upon for security boundaries.
Mitigation strategies involve applying the kernel patch that enforces strict adherence to lock hierarchies during unmount operations. System administrators should ensure their Linux kernels are updated to versions containing this fix, particularly if they run workloads relying on user namespaces and mount propagation features for container orchestration or sandboxing purposes. Furthermore, security audits of custom namespace configurations can help identify deployments that might be susceptible to similar logic errors in other parts of the VFS layer by verifying that locked mounts remain inaccessible even when their parent directories are manipulated through standard unmount commands.