Linux Kernel CVE-2026-98991

Exploitation requires a specific combination called out in the description: (1) a source mount carrying MNT_SHRINKABLE - created by finish_automount() for NFS/AFS/CIFS submounts or the tracefs mount under debugfs, with the flag inherited by bind mounts; (2) a mount namespace that has a FAN_MARK_MNTNS fanotify mark, which drives the mount-notification queuing; and (3) the ability to perform these mount operations, which an otherwise unprivileged user obtains as root inside a user namespace. The trigger is a double-queue: propagate_umount() reparents a surviving overmount and queues it 'moved', then a second umount_tree() under the same namespace_sem hold (via shrink_submounts() or mark_mounts_for_expiry()) takes down and re-queues that same mount, truncating notify_list and leaving dangling pointers. Key LIMITING factors: it is local-only (AV:L), and it is reachable by non-root users only where unprivileged user namespaces are enabled - systems that disable them (common in hardened/enterprise builds) sharply reduce exposure; it also depends on automount/fanotify features being in use.

Signals are consistent and point to a genuine but non-emergency local-privilege-class risk. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N, C:H/I:H/A:H, 7.8 HIGH) describes a local, low-complexity, low-privilege use-after-free in the Linux mount-notification path that corrupts kernel memory affecting later mount operations host-wide. EPSS is low (0.21%, 10th percentile) and the CVE is NOT in CISA KEV, so there is no evidence of active or widespread exploitation; the references are stable-tree fix commits, not exploit code, so no public PoC is identified. The vuln.today decision label is 'this_week', which aligns with the picture of a real but not emergency issue - patch on a normal cadence, not a drop-everything event. The one nuance that tempers the HIGH score is the chain of preconditions in the description (MNT_SHRINKABLE source mount, a FAN_MARK_MNTNS fanotify mark on the namespace, and the ability to act as root inside a user namespace); these are reachable by an unprivileged local user only where unprivileged user namespaces are enabled, which many hardened/enterprise configurations restrict. The input tag 'Information Disclosure' understates the mechanism - this is a slab use-after-free (memory corruption) rather than a pure read primitive - so treat impact as corruption/potential escalation; verify classification against the kernel commit.

A local unprivileged user on a system that permits user namespaces creates a user+mount namespace, applies a FAN_MARK_MNTNS fanotify mark, and induces an automount (e.g. an NFS/AFS/CIFS submount or tracefs) to obtain an MNT_SHRINKABLE mount that can be bind-mounted. By forcing multiple umount_tree() operations under one namespace_sem hold (via submount shrinking or expiry), the same reparented mount is queued twice on notify_list, so subsequent mount operations walk freed memory. No public exploit code is identified; weaponization into reliable privilege escalation would require additional heap-control work beyond the KASAN crash shown.