Answer in brief
CVE-2026-98995 records a High severity (CVSS 7.8) vulnerability in namespace: reset the old parent's ->overmount in mnt_change_mountpoint(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=ffdc52fbbd5835a936ad683c943d6d103a2d4514 <5e0a1f2c753a79749bc2ead3ae2f2ede3941daa5 || >=ffdc52fbbd5835a936ad683c943d6d103a2d4514 <08d575ee89393fd812dbdca7b5d7b4574cd5a564 || >=ffdc52fbbd5835a936ad683c943d6d103a2d4514 <476ef286a7a5db8bda51325dc0c45887b4d99d9a | 5e0a1f2c753a79749bc2ead3ae2f2ede3941daa5, 08d575ee89393fd812dbdca7b5d7b4574cd5a564, 476ef286a7a5db8bda51325dc0c45887b4d99d9a |
| Linux/Linuxgeneric | 6.17 | Not reported |
Published upstream
Oct 23, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 24, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Oct 23, 2026
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.
Quoted source text, attributed separately from HOL analysis.