ext4: fix ABBA deadlock in ext4_xattr_inode_cache_find()
Summary
| CVE | CVE-2026-92503 |
| State | PUBLISHED |
| Assigner | Linux |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-09-17 17:17:52 UTC |
| Updated | 2026-09-17 17:17:52 UTC |
| Description | 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. |
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|
| CNA |
Linux |
Linux |
affected 0a46ef234756dca04623b7591e8ebb3440622f0b 7720fddd1fe344d14be258a2028f74ebf1569511 git |
Not specified |
| CNA |
Linux |
Linux |
affected 0a46ef234756dca04623b7591e8ebb3440622f0b 03438084a7b8621fb5c762dd3d04cff5f2630fb2 git |
Not specified |
| CNA |
Linux |
Linux |
affected 0752e7fb549d90c33b4d4186f11cfd25a556d1dd git |
Not specified |
| CNA |
Linux |
Linux |
affected 737fb7853acd5bc8984f6f42e4bfba3334be8ae1 git |
Not specified |
| CNA |
Linux |
Linux |
affected 111103907234bffd0a34fba070ad9367de058752 git |
Not specified |
| CNA |
Linux |
Linux |
affected 6.1.107 6.2 semver |
Not specified |
| CNA |
Linux |
Linux |
affected 6.6.47 6.7 semver |
Not specified |
| CNA |
Linux |
Linux |
affected 6.9.7 6.10 semver |
Not specified |
| CNA |
Linux |
Linux |
affected 6.10 |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.10 semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.2.6 7.2.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.3-rc1 * original_commit_for_fix |
Not specified |
References
| Reference | Source | Link | Tags |
|---|
| git.kernel.org/stable/c/7720fddd1fe344d14be258a2028f74ebf1569511 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/03438084a7b8621fb5c762dd3d04cff5f2630fb2 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| CVE Program record |
CVE.ORG |
www.cve.org |
canonical |
| NVD vulnerability detail |
NVD |
nvd.nist.gov |
canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.