Live › vulnerability › CVE-2026-98543
Go to dashboardA BPF LSM program attached to the path_unlink or path_rmdir hook can change a file's extended attributes while the inode lock is not held. The result is a race on the victim inode's xattrs, which the sources do not show being turned into code execution.
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.
Only systems that load BPF LSM programs attached to the path_unlink or path_rmdir hooks can hit this bug. Hosts without BPF LSM programs, or with only the default kernel LSMs, can skip it.
No product ranges from the sources yet.
uname -r and compare against the fixed kernel builds listed by your distributionbpftool prog list and look for lsm programs attached to path_unlink or path_rmdirEach 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:
bpf: fs/xattr: don't assume the inode is locked in path_unlink/path_rmdir
bpf_lsm_has_d_inode_locked() makes the verifier rewrite bpf_[set|remove]_dentry_xattr() to the _locked variants, which assume that the caller already holds the inode's i_rwsem. The path_unlink and path_rmdir hooks are listed, but security_path_unlink() and security_path_rmdir() run before vfs_unlink()/vfs_rmdir() take the victim inode's i_rwsem, so a sleepable BPF LSM program attached to either hook mutates the victim's xattrs without the lock held.
Drop the two path hooks from d_inode_locked_hooks so that the verifier keeps the locking bpf_[set|remove]_dentry_xattr() variants, which take the lock themselves.
This page as .md · .json · in your agent: get_signal("CVE-2026-98543")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.