CVE-2026-92503 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix ABBA deadlock in ext4_xattr_inode_cache_find()
Syzbot/stress-ng reported an ABBA deadlock in ext4 when exercising concurrent xattr workloads (using the ea_inode mount/format option).
The deadlock occurs between the running transaction and the eviction thread: - Task 1 (stress-ng): Holds a reference to a shared mbcache_entry (ce) and calls ext4_xattr_inode_cache_find() -> ext4_iget() to retrieve the corresponding EA inode. Since the EA inode is currently being evicted, ext4_iget() blocks in __wait_on_freeing_inode() waiting for eviction to complete. - Task 2 (eviction thread): Currently evicting the same EA inode in ext4_evict_ea_inode(). It calls mb_cache_entry_wait_unused(oe) which blocks waiting for Task 1 to release the reference to the mbcache_entry.
To break this deadlock, implement a new ext4_iget() configuration flag named EXT4_IGET_NOWAIT. When set, perform a non-blocking lookup of the inode via VFS's find_inode_nowait() API.
If the inode is currently being evicted (marked with I_FREEING or I_WILL_FREE) or created (I_CREATING), or if it is not present in the VFS inode cache (cache miss), simply skip it (returning -ENOENT) rather than waiting for eviction/creation to complete, breaking the ABBA cycle.
Since we return -ENOENT immediately on a cache miss, we never attempt to allocate a new inode or call iget_locked(), completely eliminating any TOCTOU race window.
If the returned inode is I_NEW, wait for its initialization to clear via wait_on_new_inode(). If initialization fails and the inode is unhashed during wait_on_new_inode() waking up (e.g., due to an I/O read error in another thread), safely drop the reference and return -ENOENT. This unhashed check is executed unconditionally on all cache-hit pathways to properly handle concurrent initialization failures.
Finally, standard validation checks (including is_bad_inode, EXT4_EA_INODE_FL, file_acl, and xattr flags) are executed as normal inside check_igot_inode() to fully guarantee VFS-layer safety.
In ext4_xattr_inode_cache_find(), invoke ext4_iget() with the new EXT4_IGET_NOWAIT flag to perform the non-blocking cache search.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's ext4 filesystem driver contained a critical ABBA deadlock vulnerability within the extended attribute inode caching mechanism, specifically in the function ext4_xattr_inode_cache_find(). This issue was identified by Syzbot and stress-ng during concurrent workload testing that utilized the ea_inode mount option. The root cause of this defect lies in a circular dependency between two distinct kernel threads: one executing user-initiated operations and another handling inode eviction tasks. Under normal operation, when Task 1 holds a reference to a shared mbcache_entry and attempts to retrieve the corresponding extended attribute inode via ext4_iget(), it may encounter an inode that is currently being evicted by Task 2. In such scenarios, ext4_iget() traditionally blocks within __wait_on_freeing_inode(), waiting for the eviction process to complete. However, the eviction thread itself requires access to the same mbcache_entry reference held by Task 1 in order to proceed with mb_cache_entry_wait_unused(). This creates a classic lock inversion where each task waits indefinitely for the other to release its respective resource, resulting in a system hang that degrades availability and can lead to kernel panics if not resolved.
To resolve this concurrency flaw without compromising data integrity or introducing new race conditions, developers implemented a non-blocking lookup strategy through a new configuration flag named EXT4_IGET_NOWAIT for the ext4_iget() function. When this flag is active, the system utilizes the VFS layer's find_inode_nowait() API to perform immediate lookups rather than blocking on inode state changes. If the target inode is marked with flags indicating it is in a transitional state such as I_FREEING, I_WILL_FREE, or I_CREATING, or if it is absent from the cache entirely, the function immediately returns an ENOENT error code instead of waiting. This approach effectively breaks the ABBA deadlock cycle by ensuring that no thread blocks on resources held by another thread involved in the same circular dependency. By refusing to wait for eviction or creation processes, the system maintains forward progress and prevents the indefinite suspension of kernel threads.
Beyond resolving the immediate deadlock, this modification significantly enhances security posture by eliminating a potential Time-of-Check-to-Time-of-Use race condition window. Because the function returns ENOENT immediately upon cache misses without attempting to allocate new inodes or invoking iget_locked(), there is no period where an attacker could exploit the gap between checking for existence and acquiring access. Furthermore, if the lookup does succeed but encounters a newly created inode marked as I_NEW, the system waits only for its initialization to complete via wait_on_new_inode(). Crucially, this path includes robust validation logic that checks whether the inode has been unhashed during the wait period due to concurrent failures such as I/O errors. If such a condition is detected, the reference is safely dropped and ENOENT is returned, ensuring consistent behavior across all cache-hit pathways. Standard security validations including checks for bad inodes, EA inode flags, file ACLs, and xattr attributes are still performed within check_igot_inode to maintain VFS-layer safety standards.
From a vulnerability classification perspective, this issue aligns with CWE-836 which addresses the use of a resource that is subject to concurrent modification without proper synchronization mechanisms leading to race conditions or deadlocks. The operational impact primarily affects system availability and reliability under high-concurrency scenarios involving extended attributes, particularly when using specific mount options like ea_inode. Mitigation for this vulnerability involves applying kernel updates that include the fix for ext4_xattr_inode_cache_find(). System administrators should ensure their Linux distributions are updated to versions containing these patches. For environments where immediate patching is not feasible, restricting the use of concurrent extended attribute workloads or disabling the ea_inode mount option can serve as a temporary workaround to reduce exposure to this specific deadlock scenario while maintaining overall system stability and security integrity.