CVE-2026-98988
High · 8.8CVSS
8.8
EPSS
0.2%
Published
Oct 23, 2026
CISA due date
—
Cloudanix analysis
A kernel bug lets ordinary users peek behind file-system hiding tricks that container platforms use to protect sensitive areas, which could let attackers see things they are not supposed to.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Low
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Privilege Escalation
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Medium
What it actually does
The flaw permits an unprivileged user to invoke open_tree(OPEN_TREE_NAMESPACE) such that the resulting mount namespace clone omits proper locking and recursive handling, exposing mounts that were intentionally covered in the source namespace.
Why it matters to the business
Attackers can read files or directories that container runtimes or administrators intended to hide, undermining isolation boundaries used for security and multi-tenancy and increasing the chance of sensitive data exposure.
How an attack unfolds
An attacker first creates a user namespace, arranges tmpfs mounts to cover sensitive paths, then calls open_tree without AT_RECURSIVE to obtain a new mount namespace fd; after entering that namespace the previously covered content becomes directly accessible.
How to fix it
Apply the upstream kernel commit that enforces recursive copy semantics and unbindable-mount preservation for unprivileged open_tree(OPEN_TREE_NAMESPACE) callers; rebuild and deploy the fixed kernel on all affected systems.
How to confirm the fix worked
Confirm the presence of the locking and copy_mnt_ns changes in the running kernel source or binary; re-execute the mount-covering reproducer from the advisory and verify that covered paths remain inaccessible after the update.
Typical attack path
- unshare(CLONE_NEWUSER) to gain a user namespace
- mount tmpfs over target directories to cover content
- open_tree(AT_FDCWD, path, OPEN_TREE_NAMESPACE) to clone the namespace
- setns(fd, CLONE_NEWNS) to enter the new namespace
- open covered paths that should remain inaccessible
How to detect it
Audit system calls for sequences of unshare followed by open_tree with the NAMESPACE flag and subsequent setns operations; correlate with unexpected access to paths previously covered by mounts in container or sandbox environments.
What your security team should do
- Expedite kernel patching on hosts that allow unprivileged user namespaces
- Consider disabling unprivileged namespace creation via sysctl where feasible until patches are applied
- Review container runtime configurations that rely on mount namespace masking
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|