CVE-2026-80808
NoneCVSS
—
EPSS
0.2%
Published
Sep 4, 2026
CISA due date
—
Cloudanix analysis
A flaw in Linux storage handling can freeze the system when it encounters certain damaged disk structures.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Improper Input Validation
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
ext4_xattr_block_set retries indefinitely on a saturated mbcache entry whose on-disk refcount violates the EXT4_XATTR_REFCOUNT_MAX invariant, spinning while holding the parent directory i_rwsem and blocking concurrent rmdir and other directory operations.
Why it matters to the business
Systems using ext4 can experience indefinite task hangs and apparent unresponsiveness when operating on corrupted filesystems, resulting in service disruption and potential data-access outages until the affected node is restarted.
How an attack unfolds
An attacker supplies or induces filesystem metadata corruption that sets an xattr block refcount to or above the saturation value; when the kernel later selects that entry for reuse, the retry loop never marks it ineligible, causing the owning task to spin forever under the directory lock.
How to fix it
Apply the upstream ext4 fix that validates the on-disk refcount before incrementing and clears MBE_REUSABLE_B on already-saturated entries so subsequent lookups skip the unusable entry.
How to confirm the fix worked
Boot the patched kernel, run the original syzbot reproducer or equivalent filesystem corruption workload for an extended period, and confirm absence of hung-task reports and NMI backtraces referencing ext4_xattr_block_set.
Typical attack path
- Prepare or trigger ext4 metadata corruption that saturates an xattr cache entry refcount
- Perform directory operations that invoke ext4_xattr_block_set on the corrupted entry
- Enter the unbounded retry loop while holding i_rwsem
- Block all concurrent directory writers, producing a hung-task condition
How to detect it
Search kernel logs and core dumps for hung-task warnings or NMI traces that list ext4_xattr_block_set as the spinning function while holding i_rwsem; also inspect for preceding ext4 allocator or xattr corruption messages.
- ext4_xattr_block_set
- hung-task
- NMI backtrace
- i_rwsem
What your security team should do
- Upgrade to a kernel containing the reviewed overflow-safe ext4 xattr change
- Monitor dmesg and kernel logs for hung-task or ext4_xattr_block_set backtraces
- Treat ext4 volumes that have experienced allocator or xattr corruption as untrusted until repaired or replaced
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|