Cloudanix VulnDB

CVE-2026-98993

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A mistake in the Linux kernel's handling of file system mounts can let a local user crash the computer or take control of it.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The flaw in clone_mnt() copies the MNT_UMOUNT flag from lazily unmounted mounts kept alive by file descriptors on nsfs or pidfs, causing __detach_mounts(), propagate_umount(), and related functions to mishandle mount namespaces, resulting in use-after-free of struct mnt_namespace, incorrect parent chains, leaked references, and skipped unmount candidates.

Why it matters to the business

Local attackers can crash systems, leak kernel memory, or escalate privileges on Linux hosts, leading to downtime, data exposure, and full host compromise with high urgency due to the two-day-old disclosure.

How an attack unfolds

An attacker with local access performs bind mounts on /proc/self paths, opens file descriptors, lazily unmounts, then rebinds to force clone_mnt() inheritance of MNT_UMOUNT, triggering malformed mount trees that enable use-after-free during namespace teardown or propagation.

How to fix it

Apply the upstream kernel patch adding MNT_UMOUNT to MNT_INTERNAL_FLAGS in clone_mnt() and rebuild or update to the fixed kernel release; reboot affected systems after patching.

How to confirm the fix worked

Confirm the patch is present by inspecting fs/namespace.c for MNT_UMOUNT in MNT_INTERNAL_FLAGS, then test mount --bind, lazy umount, and fd-based rebind sequences to ensure no flag inheritance occurs.

Typical attack path

  1. Obtain local user access on Linux host
  2. Create bind mount to nsfs/pidfs file
  3. Open file descriptor and lazily unmount source
  4. Re-bind mount through descriptor to trigger clone_mnt
  5. Trigger namespace operations or unmount to reach UAF

How to detect it

Review kernel logs for warnings from umount_tree() on already-flagged mounts, audit mount namespace changes via auditd or bpftrace, and inspect for processes manipulating /proc/self/fd or nsfs bind mounts followed by crashes or leaks.

What your security team should do

  • Prioritize kernel updates on all Linux systems within the next 7 days
  • Restrict unprivileged mount and namespace operations via LSM policies where possible
  • Monitor for unusual mount namespace activity in production workloads

The record

In the Linux kernel, the following vulnerability has been resolved: namespace: don't inherit MNT_UMOUNT in clone_mnt() MNT_UMOUNT gets raised on a mount that umount_tree() or umount_one() has taken out of its namespace. It's never cleared. __detach_mounts() unhooks a mount that carries it instead of unmounting it. disconnect_mount() lets an unmounted child stay attached only if its parent carries it. propagate_umount() takes it as the sign that a mount is going to be unmounted when it decides what else can be unmounted, where a chain of locked mounts ends and where a for reparenting an overmount. clone_mnt() copies the flags of the source and only masks MNT_INTERNAL_FLAGS which doesn't include MNT_UMOUNT. A mount that was lazily unmounted but is kept alive by a file descriptor can still be copied when its root is an nsfs or pidfs file because may_copy_tree() accepts those before checking whether the source is mounted at all: mount --bind /proc/self/ns/net /tmp/x exec 3< /tmp/x umount -l /tmp/x mount --bind /proc/self/fd/3 /tmp/y The mount on /tmp/y is attached to the caller's namespace with MNT_UMOUNT already set and every copy of it inherits the flag again. That causes a number of bugs: - Unlink its mountpoint from a mount namespace where it isn't one. __detach_mounts() takes it for a mount that was unmounted earlier, unhooks it from its parent and drops the reference the namespace holds on it. It stays in the namespace with one reference too few and as its own parent, so it can't be unmounted through the file descriptor anymore and the namespace never finds it again. When the namespace goes away it's leaked and points to a freed struct mnt_namespace that may_change_propagation() and anon_ns_root() read on the next propagation change or mount_setattr() through the file descriptor. - Make it shared and unmount a peer. trace_transfers() follows the flag from the peer into it and strips it from its peer group. - Let a propagated umount reach it. gather_candidates() marks it with T_UMOUNT_CANDIDATE but never puts it on the candidate list, so the mark is never cleared and every later propagated umount skips it. If it's the parent of a locked mount handle_locked() takes it as the cutoff and commits the locked child that should have stayed and disconnect_mount() leaves that child attached to it, unmounted under a mounted parent, which is what disconnect_mount() exists to prevent. When the namespace goes away umount_tree() visits the child a second time. And once __detach_mounts() has made it its own parent reparent() never finds the end of the chain of unmounted parents. A clone is a new mount that has never been unmounted. Add MNT_UMOUNT to MNT_INTERNAL_FLAGS so clone_mnt() never copies it. And warn when umount_tree() reaches a mount that already has it set.

Affected packages

Ecosystem Package Introduced Fixed