high · 7.8

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

  1. 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.
  1. 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.
  2. 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

Merged from ENISA EUVD. Last updated 25 Oct 2026. All vulnerabilities · RSS · JSON