CVE-2026-31451: Linux Kernel ext4 DOS Vulnerability

CVE-2026-31451 Overview

A vulnerability has been identified in the Linux kernel's ext4 filesystem implementation within the ext4_read_inline_folio function. The issue involves improper error handling when inline data size exceeds PAGE_SIZE, where the kernel previously used a BUG_ON() assertion that could cause a kernel panic instead of gracefully handling the error condition.

The vulnerability has been resolved by replacing the BUG_ON() macro with proper error handling that prevents kernel panic and allows the system to continue running while properly reporting the filesystem corruption. The fix includes logging errors via ext4_error_inode(), releasing buffer heads to prevent memory leaks, and returning -EFSCORRUPTED to indicate filesystem corruption.

Critical Impact

Malformed ext4 filesystems with inline data exceeding PAGE_SIZE could trigger kernel panic via BUG_ON assertion, causing system denial of service.

Affected Products

• Linux Kernel (ext4 filesystem component)
• Systems using ext4 filesystems with inline data feature enabled
• Linux distributions with unpatched kernel versions

Discovery Timeline

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

Technical Details for CVE-2026-31451

Vulnerability Analysis

The vulnerability exists in the ext4 filesystem's inline data handling code within the ext4_read_inline_folio function. When processing an inode with inline data, the kernel reads the inline data size and copies it into a folio (memory page). The original code used a BUG_ON() assertion to check if the inline data size exceeded PAGE_SIZE.

The BUG_ON() macro in the Linux kernel is designed for conditions that should theoretically never occur in normal operation. However, when dealing with potentially corrupted filesystems, especially those mounted from untrusted sources such as USB drives or disk images, such conditions can be triggered maliciously or through filesystem corruption.

When BUG_ON() is triggered, it causes an immediate kernel panic, resulting in a complete system crash. This behavior is particularly dangerous in production environments where availability is critical.

Root Cause

The root cause of this vulnerability is the use of a hard assertion (BUG_ON()) for input validation in the ext4_read_inline_folio function. This assertion was placed to check that inline data size does not exceed PAGE_SIZE. However, since the inline data size is read from the filesystem metadata stored on disk, it can be manipulated by an attacker or corrupted through filesystem damage.

The kernel assumed this value would always be valid, but filesystem corruption or a maliciously crafted ext4 image can contain invalid inline data size values. This represents a violation of the security principle that input from untrusted sources (disk data) should be validated gracefully rather than asserted.

Attack Vector

The attack vector for this vulnerability involves mounting a specially crafted or corrupted ext4 filesystem that contains an inode with inline data size exceeding PAGE_SIZE. The attack scenario includes:

1. An attacker creates a malicious ext4 filesystem image with an inode containing oversized inline data metadata
2. The victim mounts the malicious filesystem (e.g., via USB drive, network share, or disk image)
3. When the kernel attempts to read the inline data from the corrupted inode, it triggers the BUG_ON() assertion
4. The kernel immediately panics, causing a denial of service

The fix addresses this by replacing BUG_ON() with proper error handling: logging the corruption via ext4_error_inode(), releasing allocated resources to prevent memory leaks, and returning -EFSCORRUPTED to the caller to indicate the filesystem corruption without crashing the system.

Detection Methods for CVE-2026-31451

Indicators of Compromise

• Unexpected kernel panics with backtrace containing ext4_read_inline_folio in the call stack
• System crash dumps showing BUG_ON assertions in ext4 filesystem code
• Suspicious ext4 filesystem images with unusually large inline data size values in inode metadata

Detection Strategies

• Monitor kernel logs for ext4-related error messages, particularly those involving inline data operations
• Implement filesystem integrity checking using e2fsck before mounting untrusted ext4 filesystems
• Deploy kernel crash dump analysis to identify patterns consistent with this vulnerability

Monitoring Recommendations

• Enable kernel crash dump collection (kdump) to capture detailed information on kernel panics for forensic analysis
• Configure system monitoring to alert on unexpected system reboots or kernel panics
• Review mounted filesystem sources and restrict mounting of untrusted external media

How to Mitigate CVE-2026-31451

Immediate Actions Required

• Apply the latest kernel patches that include the fix for CVE-2026-31451
• Restrict mounting of untrusted ext4 filesystems, especially from removable media
• Run e2fsck on ext4 filesystems before mounting images from untrusted sources
• Consider using mount options that enable read-only access for untrusted filesystems

Patch Information

The Linux kernel maintainers have released patches addressing this vulnerability across multiple stable kernel branches. The fix replaces the BUG_ON() assertion with proper error handling that logs the error, releases resources, and returns an appropriate error code.

The patches are available through the following kernel git commits:

• Kernel Git Commit 356227096eb6
• Kernel Git Commit 65c6c30ce636
• Kernel Git Commit 823849a26af0
• Kernel Git Commit a7d600e04732
• Kernel Git Commit d4b3f370c3d8

Workarounds

• Disable the inline data feature on ext4 filesystems using tune2fs -O ^inline_data /dev/device where full patching is not immediately possible
• Mount untrusted filesystems with the noexec,nosuid,nodev options to limit potential attack surface
• Use containerization or virtualization to isolate systems that must mount untrusted filesystems

# Check if inline_data feature is enabled on a filesystem
tune2fs -l /dev/sda1 | grep -i inline

# Disable inline_data feature (requires unmounting first)
umount /dev/sda1
tune2fs -O ^inline_data /dev/sda1

# Mount untrusted filesystems with restricted options
mount -o ro,noexec,nosuid,nodev /dev/sdb1 /mnt/untrusted