CVE-2026-31447: Linux Kernel Mount Rejection Vulnerability

CVE-2026-31447 Overview

CVE-2026-31447 is a flaw in the Linux kernel's ext4 filesystem driver. The kernel fails to reject mounting an ext4 filesystem when the bigalloc feature is enabled together with a non-zero s_first_data_block value. This configuration is not supported by the kernel, and mounting such a filesystem can trigger undefined behavior in filesystem operations. The fix adds an explicit validation check at mount time that rejects the unsupported combination.

The vulnerability requires local access and user interaction, typically through the mounting of a crafted filesystem image. Successful exploitation can compromise confidentiality, integrity, and availability of the host system.

Critical Impact

A local user able to mount a crafted ext4 image with bigalloc and a non-zero s_first_data_block can trigger memory corruption or kernel panic, leading to denial of service or privilege escalation.

Affected Products

• Linux Kernel (multiple stable branches addressed by upstream commits)
• Linux Kernel 7.0 release candidates rc1 through rc5
• Distributions shipping kernels with the ext4bigalloc feature enabled

Discovery Timeline

• 2026-04-22 - CVE-2026-31447 published to the National Vulnerability Database
• 2026-05-07 - Last updated in NVD database

Technical Details for CVE-2026-31447

Vulnerability Analysis

The ext4 filesystem supports an optional feature called bigalloc, which clusters multiple filesystem blocks into a single allocation unit. The kernel implementation of bigalloc assumes that the superblock field s_first_data_block is zero. When a filesystem is mounted with bigalloc enabled and s_first_data_block set to a non-zero value, internal cluster and block accounting routines compute incorrect offsets. The mount path lacked a validation check for this combination prior to the fix.

The corrected code path in the upstream commits rejects the mount and returns an error, preventing the kernel from operating on an inconsistent on-disk layout. Without the check, downstream allocation, bitmap, and extent code can read or write outside intended memory regions. This category of issue maps to filesystem-level input validation [CWE-NVD-noinfo] and is classified as a kernel filesystem flaw.

Root Cause

The ext4 mount routine did not validate the interaction between the bigalloc feature flag and s_first_data_block. The driver implicitly assumed s_first_data_block == 0 for clustered allocation but never enforced it. A crafted superblock containing both bigalloc and a non-zero first data block bypassed sanity checks and reached operational code paths that depend on the implicit assumption.

Attack Vector

An attacker requires local access and the ability to influence a mount operation, either by supplying a removable device, a loopback image, or a file in a context that triggers automatic mounting. User interaction is needed to attach or insert the malicious image. Once mounted, subsequent filesystem operations can corrupt kernel memory or panic the system. The vulnerability cannot be exploited over the network.

No public proof-of-concept exploit is available, and the issue is not listed in the CISA Known Exploited Vulnerabilities catalog. The upstream fix is distributed across multiple commits referenced in the Linux kernel stable tree.

Detection Methods for CVE-2026-31447

Indicators of Compromise

• Kernel log entries showing ext4 mount failures or oops messages referencing bigalloc cluster accounting functions
• Unexpected mount activity from non-administrative user contexts involving loopback devices or external media
• System panics or kernel BUG warnings originating from fs/ext4/ code paths shortly after a mount operation

Detection Strategies

• Audit kernel ring buffer (dmesg) output for ext4 validation errors and superblock-related warnings
• Monitor mount and losetup syscalls and correlate them with the user context performing the action
• Inspect filesystem images presented to the kernel using dumpe2fs to detect the unsupported combination of bigalloc and non-zero s_first_data_block

Monitoring Recommendations

• Forward kernel and audit logs to a centralized analytics platform for retention and correlation
• Alert on mounts of removable media or user-supplied images on production servers where this is not expected
• Track running kernel versions across the fleet and compare against the patched stable releases referenced in the upstream advisory

How to Mitigate CVE-2026-31447

Immediate Actions Required

• Apply the patched Linux kernel from your distribution vendor on all systems running affected versions
• Restrict the CAP_SYS_ADMIN capability and tighten sudo policies so untrusted users cannot mount arbitrary filesystem images
• Disable automatic mounting of removable media on multi-user servers and production hosts
• Inventory kernels in use and prioritize patching for systems exposed to untrusted local users

Patch Information

The fix is committed to the upstream Linux kernel and backported across stable branches. Reference the following upstream commits: 3822743d, 3a926957, 5ad6d994, 7b58c110, 7d5b0429, ad1f6d60, b77de3fc, and d787d3ae. Apply vendor-provided kernel updates rather than building from source where possible.

Workarounds

• Block loading of user-supplied ext4 images on hosts where the patch cannot be deployed immediately
• Use udev or systemd unit rules to prevent non-root users from triggering mount operations on removable media
• Where feasible, build kernels without the ext4bigalloc feature to eliminate the affected code path until patches are deployed

# Verify running kernel and inspect a suspect image before mounting
uname -r
sudo dumpe2fs -h /path/to/image.img | grep -E 'Filesystem features|First block'
# If output shows 'bigalloc' AND 'First block: <non-zero>', do not mount on an unpatched kernel