Cloudanix VulnDB

CVE-2026-98995

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in how the Linux kernel tracks nested file-system mounts can let a local user cause memory corruption that may crash the system or allow elevated access.

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

Use-after-free caused by failure to reset the old parent's ->overmount pointer when a mount is moved in mnt_change_mountpoint(), leaving a dangling reference that propagate_umount() and do_lock_mount() can follow into a freed mount object.

Why it matters to the business

Local attackers on affected Linux systems can trigger kernel memory corruption, leading to crashes, denial of service, or potential privilege escalation; low but non-zero exploit probability means routine patching is still required to avoid operational disruption.

How an attack unfolds

An attacker with local access opens a file descriptor that pins a mount, performs mount operations that trigger mnt_change_mountpoint() followed by reparenting and unmount, then induces do_lock_mount() or topmost_overmount() to dereference the stale ->overmount pointer into the now-freed structure.

How to fix it

Upgrade to a kernel containing the fix that resets ->overmount in mnt_change_mountpoint() identically to __umount_mnt(); apply the latest stable or distribution kernel package as soon as available and reboot affected systems.

How to confirm the fix worked

Confirm the running kernel version includes the commit that adds the reset of the old parent's ->overmount pointer; exercise mount-namespace and file-descriptor pinning test cases to verify the pointer is no longer left dangling.

Typical attack path

  1. Obtain local unprivileged shell on target Linux host
  2. Create or manipulate mount namespaces and bind mounts to set up overmount relationships
  3. Open file descriptors that keep the soon-to-be-unmounted mount alive
  4. Trigger mount move and propagate_umount sequences
  5. Force path lookup or locking operations that walk the dangling ->overmount pointer
  6. Achieve UAF read/write or kernel crash

How to detect it

Review kernel logs for oops, page faults, or warnings referencing do_lock_mount, topmost_overmount, propagate_umount, or mnt_change_mountpoint; correlate with auditd or syscall traces showing unusual mount, unmount, and namespace operations immediately preceding the crash.

What your security team should do

  • Prioritize kernel updates on all multi-user and container-host systems within the normal change window
  • Monitor upstream stable and distribution security feeds for the specific patch
  • Restrict unprivileged mount namespace creation via user namespaces where feasible until patched
  • Include kernel oops and mount-related audit events in existing anomaly detection

The record

In the Linux kernel, the following vulnerability has been resolved: namespace: reset the old parent's ->overmount in mnt_change_mountpoint() __umount_mnt() resets ->overmount of the parent when it unmounts the mount that overmounts it. mnt_change_mountpoint() doesn't. It moves the mount to its new parent and leaves the old one pointing at it. For a mount that is moved beneath in attach_recursive_mnt() that doesn't matter. The new mount has already reset ->overmount of the old parent by the time the old top mount is moved onto it. It matters for reparent() though. propagate_umount() moves a surviving overmount onto the first ancestor that isn't going to be unmounted. The mount it was taken from is unmounted immediately afterwards. If a file descriptor keeps that unmounted mount alive ->overmount points at the moved mount. That's a dangling pointer and UAF as the moved mount is unmounted and freed. do_lock_mount() follows ->overmount from the target path under mount_lock. With a file descriptor on such a mount as the target of a mount beneath topmost_overmount() walks into the freed mount and do_lock_mount() takes references on whatever it finds there. So reset ->overmount of the old parent in mnt_change_mountpoint() the same way __umount_mnt() does. A mount's ->overmount is then always a mount that is attached to it.

Affected packages

Ecosystem Package Introduced Fixed