CVE-2026-98988 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
namespace: keep covered mounts covered in OPEN_TREE_NAMESPACE
open_tree(OPEN_TREE_NAMESPACE) creates a new mount namespace from a copy of the tree at the given path. The caller needs to be privileged over its current user namespace because the new mount namespace will be owned by it. It doesn't need to be privileged over the mount namespace the tree is copied from. An unprivileged user just needs to create a user namespace first.
The copy follows the rules of a detached bind mount. Without AT_RECURSIVE only the mount itself is cloned and its children are left out. With AT_RECURSIVE unbindable mounts are skipped. Both is fine when the caller has privileges over the source mount namespace because it could unmount those mounts anyway. Not so for an unprivileged user in that mount namespace. For them a mount namespace copy is what unshare() does. copy_mnt_ns() copies everything including unbindable mounts and lock_mnt_tree() makes sure nothing can be unmounted in the copy. Nothing that was covered gets revealed.
create_new_namespace() only does the locking and so the covered content is right there in the new mount namespace:
# mount -t tmpfs none /tmp/otn; mkdir /tmp/otn/covered # echo hidden > /tmp/otn/covered/under.txt # mount -t tmpfs none /tmp/otn/covered
uid 1000, after unshare(CLONE_NEWUSER): fd = open_tree(AT_FDCWD, "/tmp/otn", OPEN_TREE_NAMESPACE); setns(fd, CLONE_NEWNS); open("/covered/under.txt", O_RDONLY) -> "hidden"
Covering paths with mounts is how container runtimes mask parts of /proc and /sys and how admins hide things.
When the caller's user namespace doesn't own the source mount namespace copy the way unshare() does and refuse a non-recursive copy of a mount that has anything mounted below the requested directory and copy unbindable mounts in a recursive copy. A caller that is privileged over the source mount namespace sees no change.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/24/2026
The Linux kernel vulnerability identified involves an improper handling of covered mounts during the creation of new mount namespaces via the open_tree system call with the OPEN_TREE_NAMESPACE flag. This function allows users to create a snapshot or copy of a portion of the current file hierarchy, establishing it as the root for a new mount namespace. While this mechanism is essential for containerization and isolation technologies that rely on creating isolated filesystem views, the implementation previously failed to correctly preserve the security properties of covered mounts when performed by unprivileged users in specific contexts. A covered mount occurs when a directory within an existing mount point has another file system mounted over it, effectively hiding or masking the underlying contents from processes not aware of the overlay. This technique is widely used by container runtimes to mask sensitive areas such as /proc and /sys, preventing containers from accessing host-specific information that could lead to privilege escalation or data leakage.
The technical flaw stems from a discrepancy in how mount namespace copies are handled based on user privileges. When an unprivileged user creates a new user namespace and subsequently uses open_tree with OPEN_TREE_NAMESPACE to copy a mount tree, the kernel did not adequately enforce the rules governing covered mounts that apply to privileged operations like unshare(). Specifically, if a directory being copied contains mounted subdirectories (covered mounts), the previous implementation might have exposed these underlying layers in the newly created namespace. This occurs because the logic for copying mounts did not sufficiently distinguish between recursive and non-recursive copies regarding unbindable mounts and covered paths when the caller lacks privileges over the source mount namespace. In contrast, privileged operations using unshare() correctly copy all mounts including unbindable ones while ensuring that nothing previously covered is revealed in the new namespace due to strict locking mechanisms like lock_mnt_tree().
The operational impact of this vulnerability allows an unprivileged user who has created a user namespace to potentially access files and directories that should be hidden by covering mounts. For instance, if an administrator or container runtime hides sensitive configuration data under a covered mount point within /tmp/otn/covered/, an attacker could exploit open_tree_namespace() to bypass these restrictions. By opening the parent directory with OPEN_TREE_NAMESPACE and switching into the new namespace, the attacker can access files such as hidden.txt located beneath the covered path. This breach of isolation undermines the security model provided by Linux namespaces, potentially leading to unauthorized data exposure or further exploitation within containerized environments where strict filesystem boundaries are critical for multi-tenant security.
This issue is categorized under CWE-250, which refers to execution with unnecessary privileges, as it allows a lower-privilege context to access resources intended to be restricted. It also relates to CWE-693, Protection Mechanism Failure, because the kernel's protection mechanism failed to enforce mount namespace isolation rules correctly for unprivileged users. From an ATT&CK perspective, this vulnerability facilitates lateral movement and privilege escalation within containerized environments by allowing attackers to break out of filesystem restrictions imposed by container runtimes. The ability to reveal covered mounts effectively breaks the containment boundary that containers rely on to isolate workloads from each other and the host system.
To mitigate this risk, kernel developers have implemented a fix that ensures open_tree with OPEN_TREE_NAMESPACE behaves consistently with unshare() regarding mount namespace copying. The updated logic now refuses non-recursive copies of mounts if they contain anything mounted below the requested directory unless the caller is privileged over the source mount namespace. For recursive copies, it correctly handles unbindable mounts to ensure no covered content is revealed in the new namespace. System administrators and container runtime developers should update their Linux kernels to versions that include this patch. Additionally, verifying that container runtimes properly utilize these updated kernel interfaces ensures that isolation guarantees remain intact for all users, regardless of their privilege level within user namespaces. Regular auditing of mount configurations and ensuring strict adherence to least-privilege principles in namespace creation further reduces the attack surface associated with such filesystem manipulation vulnerabilities.