Live › vulnerability › CVE-2026-98982
Go to dashboardA bpf token file on bpffs can be bind-mounted through /proc/self/fd, making a pseudo dentry the root of a mount. A racing lockless path walk can then use that dentry after it is freed, a use-after-free in the kernel.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Hosts running a Linux kernel with the unpatched namespace code, where a process can create a bpf token on a bpffs mount it can bind-mount. Sources do not say which kernel versions or distributions are fixed, so the exact range is unknown. Systems that do not use bpf tokens or restrict user namespaces are likely less exposed, but the sources do not confirm this.
No product ranges from the sources yet.
uname -r and compare against the fixed kernel in your distribution's advisory: unknownmount -t bpfsysctl kernel.unprivileged_userns_clone (unknown on other distributions)uname -rEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-98982")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.