Answer in brief
CVE-2026-98987 records a Unknown severity vulnerability in namespace: look at the topmost mount for a mount namespace file. 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.
A CVSS score is not reported in the current record. 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 | >=96f5d2e051653f2cfe9137c5d3c7794c358ffb03 <b9c40553f6ceba50042281eef6f701e5fb719726 || >=96f5d2e051653f2cfe9137c5d3c7794c358ffb03 <87ecd4c6da146363384a603bd9e90c90e7275536 || >=96f5d2e051653f2cfe9137c5d3c7794c358ffb03 <8714b44adac7b10506e1db3ef1710689751f0f10 | b9c40553f6ceba50042281eef6f701e5fb719726, 87ecd4c6da146363384a603bd9e90c90e7275536, 8714b44adac7b10506e1db3ef1710689751f0f10 |
| Linux/Linuxgeneric | 6.17 | Not reported |
Published upstream
Oct 23, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 23, 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: look at the topmost mount for a mount namespace file attach_recursive_mnt() preallocates a mountpoint for the root of the topmost mount of the source so that a mount that already sits at the destination can be put on top of the source or on top of one of its propagated copies. The copies are made without CL_COPY_MNT_NS_FILE so their chain of overmounts is shorter than the source's. It ends below the first bind mount of a mount namespace file. So while the loop walks up the chain of the source it remembers the mountpoint of that mount in "shorter" and the existing mount is put there for the copies. But the loop ends at the topmost mount without ever looking at it. If the topmost mount is the only mount namespace file in the chain "shorter" stays NULL and mnt_change_mountpoint() attaches the existing mount of the copy below the root of the mount namespace file. That's a dentry of nsfs. No path walk in the copy's mount namespace ever gets there. The mount is gone until its parent goes and the copy that took its place can't be unmounted synchronously because it has a child: S bind mount of a file N bind mount of a mount namespace file on top of S A shared mount, B a slave of A, Q mounted on B/file move_mount(S, A/file) cat B/file -> the content of S instead of Q umount B/file -> EBUSY Look at every mount of the chain including the topmost one.
Quoted source text, attributed separately from HOL analysis.