Linux Kernel CVE-2026-98995

Exploitation requires local access and the ability to perform mount operations - specifically the capability to create/move mounts and use the 'mount beneath'/overmount feature so that propagate_umount() and reparent() relocate a surviving overmount, combined with an open file descriptor that keeps the original unmounted mount alive to create the dangling ->overmount pointer. This typically means CAP_SYS_ADMIN in some (possibly unprivileged) user namespace where mounting is allowed. Limiting factors: no remote vector (AV:L), a privilege/mount-capability prerequisite (PR:L - not reachable by a completely unprivileged user on systems where unprivileged user namespaces or mounting are disabled), and the vulnerable code path exists only in kernels carrying the overmount/reparent logic (affected around 6.17, fixed in 6.18.57 and 7.2.11 per EUVD). Systems that disable unprivileged user namespaces materially reduce exposure.

This is a use-after-free in the Linux kernel mount namespace code (mnt_change_mountpoint() failing to reset a stale parent ->overmount pointer), and the signals are internally consistent but point to moderate, not urgent, real-world risk. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.8) correctly frames this as a local, low-complexity flaw requiring some privilege (an unprivileged local user able to perform mount operations) with full confidentiality, integrity and availability impact - the expected profile for a kernel UAF that can corrupt memory and enable local privilege escalation. The EPSS score is very low (0.21%, 10th percentile), and there is no CISA KEV listing and no public exploit reference (the only references are the three stable-tree fix commits), so there is no evidence of active exploitation or available weaponized code. The vuln.today Decision label is 'this_week', which is a moderate-priority patching cadence consistent with a locally-exploitable, non-public-exploit kernel memory-corruption bug rather than an act_now/emergency item. Note one tagging discrepancy: the input Tags label this 'Information Disclosure', but the CVSS C:H/I:H/A:H impact and the described dangling-pointer/UAF mechanism indicate memory corruption and likely local privilege escalation, which is broader than pure information disclosure - treat the 'Information Disclosure' tag as an undercharacterization, not a confirmed impact ceiling. Overall this is a legitimate issue to patch in the normal cycle but not a drop-everything emergency, given local-only access, a privilege prerequisite, low EPSS, and no observed exploitation.

A local unprivileged user with the ability to perform mount operations (for example via a user namespace where mounting is permitted) sets up a mount configuration that forces propagate_umount()/reparent() to move a surviving overmount while holding a file descriptor that keeps the original, now-unmounted, mount alive. The stale ->overmount pointer then references freed memory, and a subsequent do_lock_mount()/topmost_overmount() walk dereferences and takes references on the freed mount, yielding a use-after-free that a skilled attacker could shape into local privilege escalation. No public exploit code is identified at time of analysis; only the kernel fix commits are referenced.