CVE-2026-43067: Linux Kernel Privilege Escalation Flaw

CVE-2026-43067 Overview

CVE-2026-43067 affects the Linux kernel's ext4 filesystem code. The vulnerability resides in the block allocation logic for indirect block mapped files. A prior commit, 4865c768b563 ("ext4: always allocate blocks only from groups inode can use"), restricted block allocations for indirect block based files to block numbers that fit within 32-bit boundaries. However, the loop in ext4_mb_scan_groups_linear() can begin iterating from a group index that exceeds ngroups when the goal group originates from stream allocation through s_mb_last_groups. This allows the scanner to consider unsupported groups before the next-group helper clamps the index. The fix adds a safety clamp inside ext4_mb_scan_groups().

Critical Impact
A wraparound in ext4 group selection can permit indirect block mapped files to allocate blocks outside the 32-bit block number limit, risking filesystem corruption on mixed extent and indirect-mapped volumes.

Affected Products

Linux kernel (mainline) containing the upstream ext4 multi-block allocator
Long-term support (LTS) kernels that backported commit 4865c768b563
Distributions shipping ext4 filesystems with mixed extent-mapped and indirect block mapped inodes

Discovery Timeline

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

Technical Details for CVE-2026-43067

Vulnerability Analysis

The issue is a kernel-level boundary condition in the ext4 multi-block allocator (mballoc). The earlier commit constrained allocations for legacy indirect block mapped inodes to block groups whose block numbers fit within 32 bits. This constraint protects on-disk metadata that cannot encode 64-bit block addresses. The new flaw appears when the allocator selects a starting group from s_mb_last_groups, a per-stream cache of recently used groups. If the cached value points at a group index greater than or equal to ngroups, the linear scan begins at an out-of-range group.

Root Cause

The scan loop in ext4_mb_scan_groups_linear() initializes group = *start and invokes ext4_mb_scan_group() immediately. The helper next_linear_group(), which would normally clamp or wrap the index to a supported group, runs only at the end of each iteration. The first iteration therefore processes an unsupported group. On filesystems containing both extent mapped and indirect block mapped inodes, the allocator can pick blocks beyond the 32-bit limit for an indirect-mapped file, producing on-disk references the inode format cannot represent.

Attack Vector

Exploitation requires the ability to trigger ext4 allocations on a vulnerable kernel and a filesystem layout that mixes extent and indirect block mapped files. The condition is primarily a data integrity and stability concern rather than a code execution path. The upstream fix adds a safety clamp in ext4_mb_scan_groups() to reject out-of-range starting groups before the scan begins. The vulnerability is described in prose because no public exploit code is available. Refer to the Kernel Git Commit 4bec4a4 for the patch implementation.

Detection Methods for CVE-2026-43067

Indicators of Compromise

Kernel log entries from ext4 reporting allocation failures or block numbers exceeding the 32-bit limit on indirect block mapped inodes
Filesystem consistency errors reported by e2fsck involving block pointers in non-extent inodes
Unexpected EFSCORRUPTED return codes during write or allocation operations on legacy ext4 volumes

Detection Strategies

Inventory running kernels and compare against the fixed commits referenced in the kernel.org stable tree to identify hosts still exposed.
Audit ext4 volumes for the presence of indirect block mapped inodes using debugfs and flag systems that mix mapping types on large volumes.
Monitor dmesg and journald for ext4 allocator warnings and mballoc diagnostics that correlate with the affected code path.

Monitoring Recommendations

Enable verbose ext4 mount diagnostics on critical hosts and forward kernel logs to a centralized logging or SIEM platform for correlation.
Schedule periodic offline e2fsck -fn runs on large legacy volumes to detect block reference anomalies early.
Track kernel package versions across the fleet and alert on hosts running kernels predating the upstream fix commits.

How to Mitigate CVE-2026-43067

Immediate Actions Required

Apply the upstream ext4 patch by updating to a kernel version that includes the safety clamp in ext4_mb_scan_groups().
Identify hosts using ext4 with indirect block mapped inodes and prioritize them for patching.
Back up critical filesystems before deploying kernel updates to mitigate the risk of allocator-induced corruption during the upgrade window.

Patch Information

The fix is available across multiple stable trees. Reference commits include Kernel Git Commit 12624c5, Kernel Git Commit 2a368cc, Kernel Git Commit 4bec4a4, Kernel Git Commit 83170a0, Kernel Git Commit bb81702, and Kernel Git Commit f89bba1. Apply the kernel package update from your Linux distribution that incorporates one of these commits, then reboot.

Workarounds

Migrate legacy indirect block mapped files to extent-mapped layouts where feasible to remove the affected code path.
Avoid creating ext4 volumes that exceed 32-bit block addressing on kernels that have not received the fix.
Limit untrusted local users on multi-tenant systems running unpatched kernels until updates are deployed.

bash

# Configuration example: verify kernel version and inspect ext4 inode mapping
uname -r
debugfs -R "stat <inode>" /dev/sdaX | grep -E "Inode|EXTENTS"
dmesg | grep -i ext4