CVE-2026-31448: Linux Kernel ext4 DoS Vulnerability

CVE-2026-31448 Overview

A vulnerability has been identified in the Linux kernel's ext4 filesystem subsystem that can cause infinite loops due to residual data in the extent tree. The issue occurs during directory creation (mkdir) and device node creation (mknod) operations when mapping logical blocks to physical blocks fails, leaving stale extent tree entries that reference already-reclaimed physical blocks.

Critical Impact
This vulnerability can lead to a denial of service condition where the system becomes unresponsive for extended periods (143+ seconds reported), as ext4_xattr_block_set() enters an infinite loop and cannot release the inode lock, potentially causing system-wide blocking on ext4 filesystems.

Affected Products

Linux Kernel (ext4 filesystem subsystem)
Systems using ext4 filesystems with huge file feature disabled
Linux distributions running vulnerable kernel versions

Discovery Timeline

2026-04-22 - CVE CVE-2026-31448 published to NVD
2026-04-23 - Last updated in NVD database

Technical Details for CVE-2026-31448

Vulnerability Analysis

This vulnerability is an infinite loop condition in the Linux kernel's ext4 filesystem that leads to denial of service. The root cause lies in improper error handling within the ext4_ext_map_blocks() function during extent tree operations.

When a new extent insertion fails—for example, when the filesystem has the huge file feature disabled during inode dirty marking—the function calls ext4_free_blocks() to reclaim the physical block but fails to delete the corresponding entry from the extent tree data structure. This creates a dangerous inconsistency where the extent tree still references blocks that have been freed and potentially reallocated for other purposes.

The immediate consequence is that subsequent mkdir operations will attempt to use the previously reclaimed physical block number, even though that block may now be used by extended attributes (xattr). This results in both directory data and xattr data sharing the same buffer head block in memory simultaneously, corrupting filesystem metadata integrity.

Root Cause

The vulnerability stems from incomplete cleanup during error handling in the extent tree management code. When ext4_ext_map_blocks() encounters an error while inserting a new extent, it only performs partial cleanup by freeing the physical blocks but leaves residual data in the extent tree structure. This creates a race condition where:

A physical block is freed but its reference remains in the extent tree
The kernel allocates this block for another purpose (e.g., xattr storage)
Subsequent operations using the stale extent tree entry conflict with the new allocation
ext4_xattr_block_set() enters an infinite loop trying to reconcile the "inserted" state

The Linux kernel maintainers identified two distinct error scenarios requiring different handling: ENOSPC/EDQUOT errors (where filesystem consistency is maintained) versus other errors indicating metadata corruption (where minimal modifications should be performed to limit damage).

Attack Vector

This vulnerability can be triggered through local filesystem operations, specifically through mkdir or mknod system calls on an ext4 filesystem under specific conditions:

The ext4 filesystem must have certain features disabled (such as the huge file feature)
An operation that causes extent insertion failure must occur
Subsequent directory operations will then trigger the infinite loop

The vulnerability description indicates that when metadata corruption occurs, attempting to remove extent space can cause additional harm, and if EXT4_GET_BLOCKS_DELALLOC_RESERVE is passed, removing space incorrectly updates quota information, potentially affecting resource accounting.

Detection Methods for CVE-2026-31448

Indicators of Compromise

System processes blocked for extended periods (143+ seconds as documented in kernel traces)
Kernel log messages showing tasks blocked with call traces involving inode_lock_nested and filesystem directory operations
Processes in uninterruptible sleep state (D state) waiting on ext4 filesystem operations
High iowait or system CPU utilization without corresponding disk activity

Detection Strategies

Monitor kernel logs for "blocked for more than" messages indicating inode lock contention on ext4 filesystems
Track syz.0.17 or similar fuzzer processes that may be exercising filesystem edge cases
Implement kernel watchdog monitoring for processes stuck in start_dirop or __start_dirop functions
Use eBPF-based monitoring to detect abnormally long inode lock hold times

Monitoring Recommendations

Enable kernel hung task detection with appropriate timeout values to detect blocking conditions
Monitor for processes spending excessive time in ext4_xattr_block_set() using kernel profiling tools
Implement filesystem health checks that verify extent tree consistency periodically
Configure alerting for tasks blocked on inode operations exceeding normal thresholds

How to Mitigate CVE-2026-31448

Immediate Actions Required

Update to a patched Linux kernel version that includes the ext4 extent tree cleanup fixes
Review ext4 filesystem configurations, particularly around the huge file feature settings
Implement filesystem integrity checking (fsck) as part of maintenance routines
Consider scheduling a maintenance window to apply kernel updates on production systems

Patch Information

The vulnerability has been addressed through multiple kernel commits across different stable branches. The patches implement proper error handling that distinguishes between recoverable errors (ENOSPC, EDQUOT) and metadata corruption scenarios:

The fix ensures that for metadata corruption errors, the kernel skips freeing allocated blocks to prevent further damage and maintains extent tree consistency.

Workarounds

Ensure ext4 filesystems have consistent feature configurations to avoid triggering the error path
Consider using alternative filesystems (XFS, Btrfs) for critical systems until kernel updates can be applied
Implement process monitoring to detect and alert on blocked filesystem operations
Run e2fsck regularly to detect and repair extent tree inconsistencies before they cause issues

bash

# Check ext4 filesystem features and verify configuration
tune2fs -l /dev/sdXN | grep -E "Filesystem features|Huge file"

# Run filesystem check (unmount filesystem first)
umount /dev/sdXN
e2fsck -f /dev/sdXN

# Monitor for blocked tasks in kernel logs
dmesg | grep -E "blocked for more than|INFO: task"