Description
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.
Published: 2026-10-23
Score: 8.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Information Disclosure
Action: Apply Patch
AI Analysis

Impact

The Linux kernel function open_tree(OPEN_TREE_NAMESPACE) incorrectly copies mount trees that contain covering mounts. An attacker who can create an unprivileged user namespace can clone a source namespace that includes hidden mounts, then switch to the new namespace and access files that should remain protected by covering mounts. This flaw allows local users with only standard privileges to read data hidden from other processes, constituting a breach of confidentiality.

Affected Systems

All Linux kernels that implement open_tree and setns without the patch are affected. The issue is inherent to the kernel’s namespace handling and is not limited to a specific distribution or vendor. Any system running an unpatched kernel may be vulnerable, regardless of whether it uses container runtimes or standard user space tools.

Risk and Exploitability

The CVSS score of 8.8 marks this as a high‑severity information‑disclosure vulnerability. The EPSS score of less than 1 % suggests that exploitation is relatively uncommon, but the flaw remains locally exploitable. The attack vector is inferred to be local only, requiring the ability to create a user namespace and invoke open_tree and setns; no network interaction is needed. The vulnerability is not listed in the CISA KEV catalog. A successful exploit would allow an attacker to read files that other processes are prevented from accessing by covering mounts.

Generated by OpenCVE AI on October 29, 2026 at 21:51 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that contains the fix for the open_tree bug.
  • If unprivileged user namespaces are not required in your environment, disable them by setting /proc/sys/kernel/unprivileged_userns_clone to 0 to prevent their creation.
  • Audit and tighten container or virtualization configurations so that mount namespace operations are limited and covering mounts are enforced, ensuring that hidden file paths remain inaccessible even after namespace cloning.

Generated by OpenCVE AI on October 29, 2026 at 21:51 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 29 Oct 2026 20:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-200
CWE-732

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


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

Type Values Removed Values Added
Weaknesses CWE-200
CWE-732

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

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

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

Type Values Removed Values Added
Metrics cvssV3_1

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


Fri, 23 Oct 2026 18: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-200
CWE-284

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 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.
Title namespace: keep covered mounts covered in OPEN_TREE_NAMESPACE
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:51.817Z

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

Link: CVE-2026-98988

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

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

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

Link: CVE-2026-98988

cve-icon Redhat

Severity : Moderate

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

Links: CVE-2026-98988 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-29T22:00:09Z

Weaknesses
  • CWE-552

    Files or Directories Accessible to External Parties