In the Linux kernel, the following vulnerability has been resolved: namespace: don't let a pseudo dentry become the root of a mount d_a…
CVE-2026-98982 · GHSA-2rh7-4ph4-xmm5 · EUVD-2026-108776 · published 23 Oct 2026
How serious is it
- Severity: high, CVSS score 7.8 out of 10.
- No exploit prediction (EPSS) score yet.
- Not on the CISA list of exploited vulnerabilities.
- No public exploit in Exploit-DB.
Is your app affected by CVE-2026-98982?
Paste this prompt into Claude Code, Cursor or any AI coding tool: it runs a free Shippable scan of your project and fixes what it finds. Built with Lovable, Bolt or v0? Scan your live app. Or upload your package file.
Who is affected
- Linux Linux: patch: 6.12.113
- Linux Linux: 6.9
- Linux Linux: 35f96de04127d332a5c5e8a155d31f452f88c76d <a256e31e0c54c4c37d2523aa52faabdcdd2ebc07
- Linux Linux: 35f96de04127d332a5c5e8a155d31f452f88c76d <7e1c466011ba9e64d43075396badc03191bcee44
- Linux Linux: patch: 7.3
- Linux Linux: patch: 0
- Linux Linux: patch: 6.18.57
- Linux Linux: 35f96de04127d332a5c5e8a155d31f452f88c76d <b138e16fb1e81376cea89f727dda7bfccd140de4
- Linux Linux: patch: 7.2.11
- Linux Linux: 35f96de04127d332a5c5e8a155d31f452f88c76d <00287afa7cd989efdbf5822b7efac33cce7d489a
How to check
- Find out whether you run the affected product and which version, then compare it with the versions above.
How to fix
Copies a prompt for Claude Code, Cursor or Codex that asks it to check whether you run this product.
- Apply the vendor's update or mitigation from the references below. If there is none yet, limit exposure of the affected service until there is.
- If a vulnerable version was live, check your logs and rotate the secrets that server could read.
The advisory
In the Linux kernel, the following vulnerability has been resolved:
namespace: don't let a pseudo dentry become the root of a mount
d_alloc_pseudo() hands out dentries for pipes, sockets and other files
that are never anyone's child or parent. They carry DCACHE_NORCU and
dentry_free() frees them right away because no lockless path walk can
ever reach them. That holds as long as such a dentry isn't the root of
a mount. But bind mounting /proc/self/fd/<fd> of such a file does
exactly that.
Most callers of alloc_file_pseudo() put their files on kernel-internal
mounts and may_copy_tree() refuses those. bpf_token_create() doesn't. It
places the token file on the bpffs mount the caller handed it and that
mount is in the caller's mount namespace so the clone goes through:
mount --bind /proc/self/fd/<token> <file>
open_tree(tokfd, "", AT_EMPTY_PATH | OPEN_TREE_CLONE) + move_mount()
__follow_mount_rcu() then loads ->mnt_root of that mount, reads d_seq
and d_flags of the dentry and only then checks mount_lock. The dentry
can be gone by then. The final mntput() of an unmounted parent unhooks
a child that stayed attached to it under mount_lock alone. When the
child's holder does the final put right after that the root is dput()
and freed immediately while a walker that found the mount hashed still
looks at it.
Refuse to clone a mount with a DCACHE_NORCU dentry as its root. Nothing
sensible can be done with a bind mount of a bpf token anyway.
Check your whole app
Dependencies are only half of it. Free and read-only: before you push, run npx shippable-dev scan localhost:3000 in your project folder, no account needed. For your live app, you prove it's yours with a one-line tag first.
References
- git.kernel.org/stable/c/a256e31e0c54c4c37d2523aa52faabdcdd2ebc07
- git.kernel.org/stable/c/7e1c466011ba9e64d43075396badc03191bcee44
- git.kernel.org/stable/c/00287afa7cd989efdbf5822b7efac33cce7d489a
- git.kernel.org/stable/c/b138e16fb1e81376cea89f727dda7bfccd140de4
- nvd.nist.gov/vuln/detail/CVE-2026-98982
Merged from ENISA EUVD. Last updated 25 Oct 2026. All vulnerabilities · RSS · JSON