CVE-2026-99173 in Linux
Summary
by MITRE • 10/28/2026
In the Linux kernel, the following vulnerability has been resolved:
eventfs: Free the eventfs_inode after an rcu grace period too
tracefs_d_revalidate() reads ->is_freed of the eventfs_inode that dentry->d_fsdata points to, and ->d_revalidate() is called in rcu pathwalk mode with nothing but rcu_read_lock() held. The dentry itself stays around for such a walker, but tracefs_d_release() drops its reference to the eventfs_inode when the dentry is killed, and release_ei() then frees it after a grace period of eventfs_srcu. An SRCU grace period doesn't wait for rcu_read_lock() sections, so the walker can read an eventfs_inode that is already gone.
With a pathwalk held up in tracefs_d_revalidate() while the dentry goes away:
BUG: KASAN: slab-use-after-free in tracefs_d_revalidate+0x76/0x90 Read of size 1 at addr ff1100010152d8d0 by task walker/97 Call Trace: <TASK> tracefs_d_revalidate+0x76/0x90 lookup_fast+0x320/0x640 path_lookupat+0x160/0xb00 filename_lookup+0x1f1/0x5b0 vfs_statx+0xd7/0x3b0 vfs_fstatat+0x4d/0x90 __do_sys_newfstatat+0xa0/0x100 do_syscall_64+0x10e/0x5e0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [...]
Allocated by task 1: __kmalloc_cache_noprof+0x249/0x560 eventfs_create_dir+0x7a/0x590 event_create_dir+0x2fb/0xcf0 trace_add_event_call+0xbf/0x150 [...]
Freed by task 11: kfree+0x1db/0x5b0 srcu_invoke_callbacks+0x3a3/0x620 process_one_work+0x937/0x1810 worker_thread+0x4f1/0xd60
Before commit 8e556432477e ("eventfs: Use SRCU for freeing eventfs_inodes") release_ei() used call_rcu(), which covered the walker, while eventfs_iterate() needs the SRCU grace period. Wait for both and chain call_rcu() from the SRCU callback.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The Linux kernel vulnerability identified in the trace filesystem implementation involves a use-after-free condition within the dentry revalidation logic of the eventfs subsystem. This flaw arises from an incorrect synchronization mechanism used when freeing eventfs_inode structures, leading to potential memory corruption and system instability under specific concurrency conditions. The core issue stems from the interaction between RCU-based pathwalks and SRCU grace periods during directory traversal operations in tracefs.
The technical root cause lies in how the kernel manages the lifecycle of dentries associated with eventfs directories. When a user-space application performs file status checks or similar system calls, the VFS layer may invoke tracefs_d_revalidate to verify the validity of a dentry path. This function accesses the is_freed flag within the eventfs_inode structure pointed to by dentry->d_fsdata. During RCU-based pathwalks, which are optimized for read-heavy workloads and operate with only an rcu_read_lock held, this access occurs without holding additional locks that would prevent concurrent freeing of the underlying inode data.
The vulnerability manifests because tracefs_d_release drops its reference to the eventfs_inode when a dentry is destroyed, triggering release_ei() which schedules the memory for deallocation after an SRCU grace period completes. However, SRCU grace periods do not wait for ongoing RCU read-side critical sections to finish. Consequently, if a pathwalk operation initiated by tracefs_d_revalidate holds an RCU lock while the dentry is being released elsewhere in the system, the walker may attempt to access memory that has already been freed back to the slab allocator. This race condition results in a kernel panic or undefined behavior as detected by KASAN (Kernel Address Sanitizer), specifically manifesting as a slab-use-after-free error when reading from an address belonging to a previously allocated eventfs_inode object.
The operational impact of this vulnerability includes potential denial-of-service through system crashes, particularly on systems with high rates of tracefs directory traversal and concurrent file descriptor operations. Attackers or malicious processes could potentially exploit this race condition by carefully timing pathwalk requests against dentry release events to trigger the use-after-free scenario. While exploitation for arbitrary code execution is complex due to kernel memory protections like KASLR and SMEP/SMAP, the reliability of the system is significantly compromised as repeated triggers can lead to frequent reboots or degraded performance through OOM conditions caused by memory corruption artifacts.
This vulnerability maps directly to CWE-416: Use After Free in common weakness enumerations, reflecting the fundamental error of accessing freed memory regions. In terms of MITRE ATT&CK framework alignment, this falls under Tactic Execution with Technique T1059 Command and Scripting Interpreter if leveraged for further exploitation, though primarily it represents a stability issue classified under Defense Evasion or Impact categories depending on whether the crash is used to disrupt services. The specific mechanism involves improper synchronization between different RCU variants (RCU vs SRCU), which is a classic concurrency bug pattern in kernel development.
The resolution implemented by commit 8e556432477e addresses this issue by modifying the release_ei() function to ensure proper waiting for both RCU and SRCU grace periods. Previously, before commit 8e556432477e which introduced SRCU usage for freeing eventfs_inodes, the code used call_rcu() which correctly waited for all RCU read-side critical sections including those in pathwalks. The transition to SRCU broke this guarantee because SRCU does not synchronize with standard RCU readers. To fix this, developers chained a call_rcu callback from within the SRCU completion handler. This ensures that even after the SRCU grace period elapses and before final memory deallocation, any ongoing RCU-based pathwalks are guaranteed to have completed their access to the eventfs_inode structure.
Mitigation strategies for organizations running affected Linux kernels include immediate patching through vendor-provided updates or backported fixes from upstream kernel repositories. Administrators should monitor system logs for KASAN-related panic messages which indicate potential exploitation attempts or accidental triggers of this race condition. For systems where immediate patching is not feasible, reducing the frequency of tracefs directory operations and avoiding concurrent high-volume file status checks on eventfs paths can reduce the probability window for triggering the vulnerability. Long-term architectural improvements should focus on standardizing RCU usage patterns across filesystem implementations to prevent similar synchronization mismatches in future kernel versions.