Cloudanix VulnDB

CVE-2026-98982

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in the Linux kernel could let a local user with limited rights gain full control of the computer by tricking the system into using a temporary file reference after it has already been deleted.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in Linux kernel mount handling: a DCACHE_NORCU pseudo dentry obtained via d_alloc_pseudo (used for pipes, sockets, BPF tokens) can become the root of a cloned mount when bpf_token_create places the file on a user-visible bpffs mount; subsequent __follow_mount_rcu and final mntput races free the dentry while a walker still holds a reference.

Why it matters to the business

Local attackers on affected Linux systems can potentially achieve kernel code execution or denial of service, risking full host compromise; the bug is two days old with no known exploitation yet, but kernel flaws of this class are high-value targets for privilege escalation.

How an attack unfolds

An attacker obtains a BPF token file descriptor, performs a bind mount of /proc/self/fd/<token> followed by open_tree with OPEN_TREE_CLONE and move_mount, then races an unmount of a parent mount so that the final mntput frees the pseudo dentry under mount_lock while an RCU walker still dereferences it.

How to fix it

Upgrade to a Linux kernel containing the upstream fix that refuses to clone any mount whose root dentry has DCACHE_NORCU set; rebuild and reboot all affected hosts with the patched kernel.

How to confirm the fix worked

Confirm the kernel source contains the new check in may_copy_tree / clone_mount that rejects DCACHE_NORCU roots; run regression tests exercising bpf_token_create followed by mount cloning and verify no UAF warnings appear under KASAN or lockdep.

Typical attack path

  1. Obtain BPF token via bpf_token_create on a user-visible bpffs mount
  2. Bind-mount the token fd and clone the mount tree with open_tree + move_mount
  3. Trigger concurrent unmount of an ancestor mount to race dentry lifetime
  4. Use the freed dentry object for arbitrary read/write or control-flow hijack

How to detect it

Search kernel audit logs and system-call traces for sequences of bpf, open_tree, move_mount, and bind-mount operations on /proc/self/fd paths; monitor for dentry-related kernel warnings, oops, or RCU stalls immediately following mount namespace manipulation.

What your security team should do

  • Prioritize kernel updates on all multi-user and container hosts within the next 7 days
  • Temporarily restrict unprivileged BPF token creation and mount namespaces via seccomp or LSM policies where feasible
  • Enable KASAN or similar kernel debugging on test fleets to surface latent UAFs
  • Review auditd and eBPF telemetry for unusual open_tree, move_mount, and bpf system-call sequences

The record

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.

Affected packages

Ecosystem Package Introduced Fixed