CVE-2026-92503: ext4: fix ABBA deadlock in ext4_xattr_inode_cache_find()
ext4: fix ABBA deadlock in ext4xattrinodecachefind()
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.159.1-1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.114 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.57 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.6 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.6-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.12-1Fixed in 7.2.14-1
Event History
Frequently Asked Questions
Which systems are exposed to this deadlock?
The reported condition involves ext4 filesystems using the ea_inode mount or format option while handling concurrent extended-attribute workloads. It requires contention between xattr lookup activity and eviction of the same EA inode.
What runtime evidence would indicate this condition is occurring?
One task can be blocked in ext4_iget() through __wait_on_freeing_inode() while waiting for an EA inode eviction to finish. At the same time, the eviction thread can be blocked in mb_cache_entry_wait_unused() waiting for the first task to release its shared mbcache entry reference.
How does the fix avoid the deadlock?
The fix adds EXT4_IGET_NOWAIT, causing the affected lookup to use a non-blocking VFS inode lookup. If the inode is being created or evicted, or is absent from the inode cache, the lookup does not wait for it.