Cloudanix VulnDB

CVE-2026-98991

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 Linux tracks file system mounts can let a local user crash the computer or possibly 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

Use-after-free in Linux kernel mount notification queueing where a mount can be added to notify_list multiple times under one namespace_sem hold, causing later mount operations to walk freed list entries.

Why it matters to the business

Local attackers on Linux systems can trigger kernel memory corruption leading to crashes or potential privilege escalation; the bug affects kernels handling automounts and mount namespaces.

How an attack unfolds

An attacker creates a user namespace, sets up MNT_SHRINKABLE automounts (NFS/AFS/CIFS or tracefs), applies a FAN_MARK_MNTNS fanotify mark, then triggers multiple umount_tree calls via bind mounts or submount expiry to cause double list_add_tail and subsequent use-after-free on freed mounts.

How to fix it

Update to a kernel containing the fix that initializes to_notify in alloc_vfsmnt and skips already-queued mounts before list_add_tail; disable unprivileged user namespaces as a temporary mitigation where feasible.

How to confirm the fix worked

Confirm the kernel source includes the check for prior queuing in mnt_notify_add and the to_notify initialization; reproduce the original KASAN report to verify absence after patching.

Typical attack path

  1. Enter a user namespace with mount capabilities
  2. Create automount points that receive MNT_SHRINKABLE flag
  3. Register fanotify mark with FAN_MARK_MNTNS on the namespace
  4. Perform bind mounts or operations that invoke propagate_umount and multiple umount_tree calls under one namespace_sem
  5. Trigger path_mount to walk the corrupted notify_list

How to detect it

Search kernel logs and crash dumps for KASAN reports containing __list_add_valid_or_report called from mnt_add_to_ns during attach_recursive_mnt or path_mount; look for slab-use-after-free on notify_list structures.

  • BUG: KASAN: slab-use-after-free in __list_add_valid_or_report
  • mnt_add_to_ns
  • attach_recursive_mnt.isra
  • notify_list still pointing at them

What your security team should do

  • Apply the upstream mount notification fix immediately on all Linux hosts
  • Restrict unprivileged user namespaces via sysctl where business needs allow
  • Monitor kernel logs for KASAN slab-use-after-free reports involving mnt_add_to_ns

The record

In the Linux kernel, the following vulnerability has been resolved: namespace: queue a mount only once for mount notifications mnt_notify_add() puts a mount on notify_list. It doesn't check whether the mount is on the list already. That's fine as long as every mount is queued at most once per namespace_sem hold. It isn't. propagate_umount() moves a surviving overmount off a stack of mounts that are going away and queues it as moved. shrink_submounts() and mark_mounts_for_expiry() call umount_tree() for several mounts under a single namespace_sem hold. So the second umount_tree() can take down exactly the mount the first one reparented, reparent it once more and so end up queueing it a second time. The second list_add_tail() cuts the mounts queued in between out of the list while the head still points at the last of them. notify_mnt_list() then only visits that one mount and the others are freed after the grace period with notify_list still pointing at them. Every later mount operation on the host walks freed memory: BUG: KASAN: slab-use-after-free in __list_add_valid_or_report Read of size 8 at addr ffff8881003d57e0 by task notify_dq/162 __list_add_valid_or_report+0x15c/0x1a0 mnt_add_to_ns+0x322/0x890 attach_recursive_mnt.isra.0+0xf2a/0x1a00 path_mount+0x139c/0x1d40 This needs a mount with MNT_SHRINKABLE to bind from. That's what finish_automount() creates (submounts of NFS, AFS and CIFS and the tracefs mount below debugfs). Bind mounts inherit the flag. A mount namespace with a FAN_MARK_MNTNS mark does the rest and root in a user namespace can have both. Initialize to_notify in alloc_vfsmnt() and leave a mount alone that is queued already. mnt_notify() looks at the state the mount has when the list is drained so a single entry per mount is enough. The move event for a mount that is unmounted under the same hold is lost. That's fine. The detach is what matters.

Affected packages

Ecosystem Package Introduced Fixed