CVE-2026-80808 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
ext4: stop retrying saturated xattr cache entries
ext4_xattr_block_set() retries when a cache entry selected for reuse has a saturated reference count after taking the buffer lock. The retry returns to the mbcache lookup without making that entry ineligible, so it can select the same unusable entry indefinitely. A task spinning there can hold the parent directory's i_rwsem and leave concurrent rmdir callers blocked.
Normally a reusable entry has a reference count below EXT4_XATTR_REFCOUNT_MAX because the count and MBE_REUSABLE_B are updated under the same buffer lock. A corrupted filesystem can violate that invariant. The syzbot reproducer reports allocator and xattr corruption before triggering this retry loop.
Check the untrusted on-disk count before incrementing it, avoiding overflow, and clear MBE_REUSABLE_B when it is already saturated. The next lookup then skips the entry that was just proven unusable. This mirrors the normal transition at EXT4_XATTR_REFCOUNT_MAX; the release path marks the entry reusable again on the exact 1024-to-1023 transition.
Using the same QEMU harness and guest parameters, current unpatched Linux hung in 6 of 8 420-second trials with the do_rmdir signature; representative NMI backtraces caught the owner spinning in ext4_xattr_block_set(). The patched kernel completed 28 of 28 trials without a hung-task report; the final twelve trials exercised the reviewed overflow-safe form of the change. syzbot's patch testing also completed without reproducing the hang.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/05/2026
The Linux kernel ext4 filesystem driver contains a logic flaw within the extended attribute (xattr) block management subsystem that can lead to indefinite task spinning and subsequent denial of service conditions. Specifically, the function ext4_xattr_block_set() is responsible for managing cache entries used to store xattrs on disk blocks. When attempting to reuse an existing cache entry, the code checks if the entry's reference count indicates it is saturated or full. If a selected entry has reached its maximum reference capacity, the logic attempts to retry by returning to the mbcache lookup mechanism without properly marking that specific entry as ineligible for immediate re-selection. This oversight allows the allocator to repeatedly select the same unusable, saturated entry in subsequent iterations of the loop. Consequently, the task executing this operation enters a tight spin loop, consuming CPU resources indefinitely while holding critical locks such as the parent directory's i_rwsem semaphore.
This behavior creates a significant operational impact by blocking concurrent operations that require access to the affected directory structure. Most notably, remote or local users attempting to perform recursive directory removal (rmdir) operations are blocked because they cannot acquire the necessary read-write lock on the parent inode. The spinning task effectively holds up these system calls, leading to hung tasks and potential denial of service for other processes interacting with that part of the filesystem hierarchy. While this issue is typically triggered by a corrupted filesystem where internal invariants regarding reference counts are violated, it represents a robustness failure in handling untrusted or malformed on-disk data structures rather than requiring complex exploitation techniques from an attacker perspective.
The root cause lies in how the kernel handles reference count validation during cache entry reuse. Normally, reusable entries maintain a reference count below EXT4_XATTR_REFCOUNT_MAX because both the count and the MBE_REUSABLE_B flag are updated under the protection of the buffer lock, ensuring consistency. However, when dealing with corrupted filesystem images or maliciously crafted disk structures, this invariant can be broken. The vulnerability arises because the code did not sufficiently validate the untrusted on-disk reference count before attempting to increment it or reuse the entry. This lack of validation allowed saturated entries to remain in the pool of reusable candidates despite being functionally unusable for further allocation attempts.
The resolution involves implementing strict validation checks before modifying cache state. The patch ensures that the kernel verifies the current value of the on-disk reference count against the maximum limit before any increment operation occurs, thereby preventing integer overflow or logical errors associated with saturated entries. Furthermore, when an entry is found to be already saturated, the code now explicitly clears the MBE_REUSABLE_B flag. This action effectively removes the unusable entry from consideration in future lookups within that cycle, forcing the allocator to search for a different cache block. This approach mirrors the standard transition logic used at EXT4_XATTR_REFCOUNT_MAX and ensures that entries proven to be invalid are not repeatedly selected, thus breaking the infinite retry loop.
From a security classification perspective, this vulnerability aligns with CWE-835, which describes loops of death or spin loops resulting from improper synchronization or state management. It also relates to CWE-20 regarding Improper Input Validation, as the kernel failed to adequately validate untrusted data derived from disk structures before processing it within critical locking contexts. In terms of adversarial tactics, this scenario reflects aspects of ATT&CK technique T1496, Resource Hijacking, where an attacker or corrupted state causes a system resource such as CPU time and locks to be consumed excessively, degrading service availability for legitimate users.
Mitigation strategies primarily involve applying the upstream kernel patch that addresses the ext4 xattr cache logic. System administrators should ensure their Linux distributions are updated with versions containing this fix. For environments where immediate patching is not feasible, monitoring tools can be configured to detect hung tasks associated with directory operations or excessive CPU usage by processes interacting with filesystem metadata. Additionally, ensuring filesystem integrity through regular checks and avoiding the mounting of untrusted or potentially corrupted disk images can reduce the risk of triggering this specific code path in production environments.