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:

1. A physical block is freed but its reference remains in the extent tree
2. The kernel allocates this block for another purpose (e.g., xattr storage)
3. Subsequent operations using the stale extent tree entry conflict with the new allocation
4. 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:

1. The ext4 filesystem must have certain features disabled (such as the huge file feature)
2. An operation that causes extent insertion failure must occur
3. 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:

• Kernel Commit 3a7667595bcad84da53fc156a418e110267c3412
• Kernel Commit 416c86f30f91b4fb2642ef6b102596ca898f41a5
• Kernel Commit 5422fe71d26d42af6c454ca9527faaad4e677d6c
• Kernel Commit 64f425b06b3bea9abc8977fd3982779b3ad070c9
• Kernel Commit c66545e83a802c3851d9be27a41c0479dd29ff0c
• Kernel Commit ecc50bfca9b5c2ee6aeef998181689b80477367b

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

# 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"