CVE-2026-74605 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
eventfs: Use children field for rcu head and add memory barriers
When an eventfs inode is freed, it sets ei->is_freed and then uses its ei->list to add it to the srcu link list as the list field is a union with the rcu list head. As the ei->list is used to iterate over an SRCU protected list without taking the eventfs_mutex, there's nothing stopping the iteration over that list to see the ei->rcu instead of the ei->list and it will read a corrupt target.
To fix this, change the union of the rcu list head with the children list. On freeing the eventfs inode, set the is_free and execute a smp_wmb() before adding the eventfs inode to the SRCU list.
On iteration of the ei->children list, at the start, execute a smp_rmb() and then read the is_freed of the ei to see if the children list is still valid. If is_freed is set, then the ei_child read is not valid and the loop should exit immediately.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel eventfs subsystem contains a concurrency vulnerability related to race conditions during inode lifecycle management, specifically involving the interaction between memory deallocation and concurrent list iteration protected by Source Read-Copy-Update mechanisms. The core issue stems from the use of a union data structure where the rcu_head for deferred reclamation shares memory space with the children list head used for traversing child inodes. When an eventfs inode is scheduled for freeing, the kernel sets an internal flag indicating that the inode has been freed and subsequently adds it to the SRCU protected link list using this shared field. Because the iteration over the SRCU-protected list occurs without holding the eventfs mutex, there exists a critical window where concurrent readers may observe the memory state during or after the transition from active use to reclamation.
This race condition allows an iterating thread to potentially read corrupted data because it might access the rcu_head structure instead of the intended children list head before proper synchronization barriers are established in all execution paths. The lack of explicit memory ordering guarantees means that a reader could see the updated pointer value for the RCU callback while simultaneously seeing stale or inconsistent values for other fields within the inode structure, leading to use-after-free scenarios or invalid memory accesses. This flaw represents a classic instance of improper synchronization in concurrent data structures where the order of operations regarding flag setting and list insertion is not strictly enforced across different CPU cores.
From a classification perspective, this vulnerability aligns with CWE-362, which describes Concurrent Execution using Shared Resource with Improper Synchronization, commonly known as race conditions. Furthermore, it relates to CWE-416, Use After Free, as the potential for accessing invalid memory structures during the transition phase can lead to dereferencing freed or corrupted objects. In terms of adversary behavior and detection, this type of kernel-level concurrency bug could be leveraged in attacks categorized under MITRE ATT&CK technique T1059, Command and Scripting Interpreter, if exploited to gain elevated privileges, or more broadly within the Privilege Escalation tactics where an attacker exploits a race condition to bypass security restrictions.
The resolution involves restructuring the memory management logic by changing how the union is utilized during the freeing process. The fix mandates that when an eventfs inode is freed, the system must first set the is_freed flag and then execute a write memory barrier before adding the inode to the SRCU list. This ensures that any subsequent reads will observe the correct state of the flags relative to the list insertion operation. Additionally, on the reading side, during iteration over the children list, an explicit read memory barrier is executed at the start of each loop iteration followed by a check of the is_freed flag. If this flag indicates the inode has been freed, the reader immediately exits the loop, preventing access to potentially corrupted or invalid child data structures.
To mitigate similar issues in kernel development and ensure robustness against concurrency bugs, developers should strictly adhere to memory barrier protocols when dealing with shared resources accessed by multiple threads without exclusive locks. It is crucial to separate distinct logical states within union types if they are subject to concurrent modification and access patterns that do not rely on heavy locking mechanisms like mutexes. Implementing explicit read and write barriers as demonstrated in the fix ensures proper ordering of memory operations across CPU cores, thereby preventing stale data reads or partial updates from being observed by other threads. Regular static analysis tools focused on concurrency issues and formal verification methods can also help identify such race conditions before they reach production kernels.