CVE-2026-43068: Linux Kernel ext4 DOS Vulnerability

CVE-2026-43068 Overview

CVE-2026-43068 is a Linux kernel vulnerability in the ext4 filesystem block allocator. The flaw resides in ext4_mb_find_by_goal(), where the kernel may attempt to allocate blocks from a block group already flagged as corrupted. When ext4_mb_load_buddy() returns an error indicating block bitmap corruption, the calling path does not properly recognize the corrupted group state. This causes repeated delayed block allocation failures with error 117 (-EFSCORRUPTED) and triggers "Data will be lost" warnings in the kernel log.

Critical Impact
Repeated allocation attempts against corrupted ext4 block groups cause delayed block allocation failures, resulting in data loss for affected inodes on the filesystem.

Affected Products

Linux kernel versions containing commit 9008a58e5dce ("ext4: make the bitmap read routines return real error codes") prior to the fix
Linux distributions shipping vulnerable upstream ext4 code
Stable kernel branches addressed by patch commits 0b84571, 1895f79, 1c0d7c4, 2d31a50, 46066e3, 9370207, fea6b2e, and ffc0a28

Discovery Timeline

2026-05-05 - CVE-2026-43068 published to NVD
2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-43068

Vulnerability Analysis

The vulnerability affects the multi-block allocator in the ext4 filesystem. The function ext4_mb_find_by_goal() calls ext4_mb_load_buddy(), which invokes ext4_mb_init_cache() and ultimately ext4_validate_block_bitmap(). When the validator detects that EXT4_MB_GRP_BBITMAP_CORRUPT(grp) is true, it returns -EFSCORRUPTED without emitting a warning log.

The caller in ext4_mb_find_by_goal() then returns the error directly. A subsequent corruption check inside ext4_lock_group() is unreachable because execution never proceeds past the failed ext4_mb_load_buddy() call. The allocator therefore keeps targeting the same corrupted group on every retry, producing repeated Delayed block allocation failed errors with error code 117 and inode-level data loss messages.

Root Cause

After commit 9008a58e5dce changed bitmap read routines to return real error codes, the earlier mitigation in commit 163a203ddb36 ("ext4: mark block group as corrupt on block bitmap error") became ineffective. The corruption flag check sits behind a code path that is no longer reached when ext4_mb_load_buddy() short-circuits on error, so the allocator never skips the corrupted group and never selects an alternative.

Attack Vector

Triggering the condition requires an ext4 filesystem with at least one block group whose bitmap is already marked corrupt. Workloads performing buffered writes against inodes that target that group through the goal-based fast path will repeatedly hit the failure. The issue manifests as a local data integrity and availability problem rather than a remote code execution vector. The fix adds an explicit check of the corrupted block group flag when ext4_mb_load_buddy() returns an error, allowing the allocator to fall through to other groups.

Detection Methods for CVE-2026-43068

Indicators of Compromise

Repeated kernel log entries: EXT4-fs: Delayed block allocation failed for inode <N> at logical offset 0 with max blocks 1 with error 117
Kernel messages reading This should not happen!! Data will be lost
Initial and last error references to ext4_mb_generate_buddy:760 in dmesg or /var/log/messages
Increasing error count since last fsck reported by ext4 superblock metadata

Detection Strategies

Monitor dmesg and journald for EXT4-fs errors referencing error code 117 and ext4_mb_generate_buddy
Inspect ext4 superblocks with dumpe2fs -h <device> to read Filesystem errors, First error time, and Last error time fields
Track running kernel version against vendor advisories listing the patch commits referenced for this CVE

Monitoring Recommendations

Forward kernel logs to a centralized logging or SIEM platform and alert on repeated Delayed block allocation failed events on the same inode
Add storage health checks that flag filesystems showing growing ext4 error counters between scheduled fsck runs
Correlate I/O error spikes and application write failures with kernel filesystem messages on the affected host

How to Mitigate CVE-2026-43068

Immediate Actions Required

Apply the upstream Linux kernel patches identified by commits 0b84571, 1895f79, 1c0d7c4, 2d31a50, 46066e3, 9370207, fea6b2e, and ffc0a28 to all affected stable branches
Schedule offline e2fsck -fy <device> on filesystems already showing ext4 corruption messages to repair damaged block groups
Back up data on any filesystem reporting Delayed block allocation failed before performing repair operations

Patch Information

The upstream fix updates ext4_mb_find_by_goal() to check the EXT4_MB_GRP_BBITMAP_CORRUPT flag when ext4_mb_load_buddy() returns an error, allowing the allocator to skip corrupted groups instead of returning failure. Refer to the Kernel Patch Commit ffc0a28 and the related stable backports listed in the NVD references for the full change set.

Workarounds

Run e2fsck to clear corruption on affected block groups, since the bug only triggers when a group is already marked corrupt
Migrate data to a freshly created ext4 volume when repair is not feasible, eliminating the corrupted group entirely
Where supported by the workload, mount the filesystem read-only until the kernel can be updated to limit further allocation attempts

bash

# Verify kernel version and inspect ext4 error state
uname -r
sudo dumpe2fs -h /dev/mmcblk0p1 | grep -E 'error|Filesystem features'
sudo dmesg | grep -E 'EXT4-fs|ext4_mb_generate_buddy'

# Repair affected filesystem (unmount first)
sudo umount /dev/mmcblk0p1
sudo e2fsck -fy /dev/mmcblk0p1