CVE-2026-99051 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
fsverity: RCU-delay the freeing of struct fsverity_info
__fsverity_get_info() calls rhashtable_lookup_fast(), which just uses rcu_read_lock() and doesn't directly synchronize with fsverity_remove_info().
For the same inode this isn't a problem: its fsverity_info is removed only at inode eviction time or upon failure to enable verity, when the inode no longer needs its fsverity_info and it will no longer be accessed via that inode.
However, this is broken and can cause a use-after-free for concurrent __fsverity_get_info() for *different* inodes. Those rely on following fsverity_info::rhash_head in the rhashtable under rcu_read_lock() only. They also use fsverity_info::inode to do the key comparison.
Fix this by RCU-delaying the freeing of 'struct fsverity_info' after it's been removed from the rhashtable.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel implementation of file system verity contains a concurrency flaw within the mechanism used to manage and retrieve integrity metadata structures, specifically involving the struct fsverity_info object. This vulnerability arises from an improper synchronization strategy when accessing shared data structures that are subject to concurrent modification by multiple threads or processes operating on different inodes. The core issue lies in how the kernel handles the lifecycle of these information structures within a hash table lookup operation, leading to potential memory safety violations under specific race conditions.
The technical flaw centers on the interaction between __fsverity_get_info() and fsverity_remove_info(). When __fsverity_get_info() is invoked, it utilizes rhashtable_lookup_fast(), which relies solely on rcu_read_lock() for read-side synchronization. This approach assumes that any data structure accessed during this critical section will remain valid until the RCU read lock is released. However, while the removal of fsverity_info associated with a specific inode is safely synchronized because it occurs only at inode eviction or upon failure to enable verity—times when no further access via that inode is possible—the situation differs for concurrent operations on different inodes. In these cases, multiple threads may be traversing the rhashtable simultaneously. One thread might remove an fsverity_info structure from the hash table and immediately free it, while another thread is still holding an RCU read lock and attempting to dereference pointers within that same struct, such as following the fsverity_info::rhash_head or accessing fsverity_info::inode for key comparison.
This race condition results in a use-after-free vulnerability, classified under CWE-416: Use After Free. An attacker who can trigger concurrent file system verity operations on different files may exploit this timing window to cause undefined behavior within the kernel space. The operational impact of such a flaw is severe, as it compromises the stability and security integrity of the operating system. Successful exploitation could lead to kernel panics, denial of service conditions where the system becomes unresponsive or crashes, or potentially arbitrary code execution if an attacker can carefully craft memory states to hijack control flow during the dereference of freed memory. This undermines the reliability guarantees provided by the file system verity feature, which is designed to ensure data integrity and authenticity.
The resolution involves modifying the kernel's handling of struct fsverity_info deallocation to adhere strictly to RCU semantics. By implementing an RCU-delayed free mechanism, the kernel ensures that once a structure is removed from the rhashtable, it remains in memory long enough for all pre-existing RCU read-side critical sections to complete their execution before the actual memory release occurs. This typically involves using call_rcu() or similar mechanisms to schedule the freeing of the object after a grace period has elapsed, during which no new readers can acquire references that would outlive the old ones. This fix aligns with standard practices for managing shared data structures in concurrent environments and mitigates the risk associated with premature memory reclamation.
From a defensive perspective, this vulnerability highlights the critical importance of correct RCU usage patterns when dealing with hash tables or other dynamic collections accessed under read locks. Security practitioners should ensure that kernel updates are applied promptly to mitigate these low-level concurrency bugs. Furthermore, static analysis tools and formal verification methods can be employed during development phases to detect similar synchronization errors before they reach production kernels. The mitigation strategy reinforces the principle that any data structure accessible via RCU-protected pointers must not be freed until all potential readers have had sufficient time to finish their access cycles, thereby preserving memory safety in multi-threaded kernel contexts.