CVE-2026-98543 in Linux
Summary
by MITRE • 10/18/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel contains a vulnerability within its BPF LSM (Linux Security Module) subsystem related to incorrect assumptions about inode locking during file system operations. Specifically, the function bpf_lsm_has_d_inode_locked incorrectly identifies certain security hooks as requiring or assuming that the target inode is already locked with an i_rwsem semaphore. This misclassification causes the BPF verifier to rewrite calls to bpf_set_dentry_xattr and bpf_remove_dentry_xattr into their _locked variants, which expect the caller to hold the necessary locks before mutating extended attributes on a dentry or inode. The hooks in question are security_path_unlink and security_path_rmdir, which are invoked during directory entry removal operations such as unlinking files or removing directories.
The core technical flaw arises from the timing of lock acquisition relative to hook execution. When vfs_unlink or vfs_rmdir is called, it eventually takes the victim inode's i_rwsem semaphore before performing the actual deletion. However, the security_path_unlink and security_path_rmdir hooks are executed earlier in the call chain, prior to this lock being acquired by the VFS layer. Consequently, any sleepable BPF LSM program attached to these hooks that attempts to modify extended attributes on the victim inode does so without holding the required i_rwsem lock. This creates a race condition where concurrent access to the same inode can lead to data corruption or undefined behavior due to unsynchronized modifications of xattrs.
This vulnerability falls under CWE-362, which describes Concurrent Execution using Shared Resource with Improper Synchronization, specifically involving critical sections and locking mechanisms. From an ATT&CK perspective, this relates to techniques that exploit improper synchronization in kernel-level components, potentially allowing for privilege escalation or denial of service if exploited by a malicious BPF program attached to these hooks. The impact is particularly severe because it affects the integrity of file system metadata operations at the kernel level, which are fundamental to operating system stability and security enforcement.
The resolution involves removing path_unlink and path_rmdir from the d_inode_locked_hooks list within the kernel source code. By doing so, the BPF verifier no longer assumes that these hooks run with the inode locked, and thus continues to use the standard bpf_set_dentry_xattr and bpf_remove_dentry_xattr functions instead of their _locked variants. These standard variants internally acquire the necessary i_rwsem lock themselves before performing any mutations on extended attributes. This ensures proper synchronization regardless of when during the VFS operation the hook is executed, thereby eliminating the race condition and restoring correct locking semantics for BPF LSM programs interacting with file system metadata.
Mitigation strategies include applying the kernel patch that addresses this issue by updating the d_inode_locked_hooks configuration to exclude path_unlink and path_rmdir hooks. System administrators should ensure their Linux kernels are updated to versions containing this fix, particularly those running environments where custom BPF security modules are deployed for enhanced access control or auditing purposes. Regularly monitoring for updates from kernel maintainers is essential as similar synchronization issues may exist in other parts of the VFS subsystem. Additionally, organizations deploying BPF-based security solutions should review their LSM programs to ensure they adhere to proper locking protocols when modifying inode attributes across various file system operations.