CVE-2026-43068
Description
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()
There's issue as follows: ... EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): error count since last fsck: 1 EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760 EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760 ...
According to the log analysis, blocks are always requested from the corrupted block group. This may happen as follows: ext4_mb_find_by_goal ext4_mb_load_buddy ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_wait_block_bitmap ext4_validate_block_bitmap if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp)) return -EFSCORRUPTED; // There's no logs. if (err) return err; // Will return error ext4_lock_group(ac->ac_sb, group); if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) // Unreachable goto out;
After commit 9008a58e5dce ("ext4: make the bitmap read routines return real error codes") merged, Commit 163a203ddb36 ("ext4: mark block group as corrupt on block bitmap error") is no real solution for allocating blocks from corrupted block groups. This is because if 'EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)' is true, then 'ext4_mb_load_buddy()' may return an error. This means that the block allocation will fail. Therefore, check block group if corrupted when ext4_mb_load_buddy() returns error.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
In the Linux kernel's ext4 filesystem, a missing check for a corrupted block group bitmap in ext4_mb_find_by_goal() can cause repeated allocation failures and data loss.
Vulnerability
Description
CVE-2026-43068 is a vulnerability in the Linux kernel's ext4 filesystem. The issue resides in the ext4_mb_find_by_goal() function, which is responsible for allocating blocks from a specific block group. When the block group's bitmap is corrupted, the function ext4_mb ext4_mb_load_buddy_gfp() may return an error (-EFSCORRUPTED) after validating the bitmap. However, the code in ext4_mb_find_by_goal() does not properly handle this error and continues to attempt allocation from the same corrupted group, leading to repeated failures [1][2].
Exploitation and
Attack Surface
An attacker with the ability to trigger filesystem operations on a corrupted ext4 filesystem (e.g., by mounting a maliciously crafted image or causing on-disk corruption) can cause the kernel to repeatedly attempt block allocation from a corrupted block group. This does not require special privileges beyond the ability to perform file I/O on the affected filesystem. The attack surface is local, as it involves direct access to the filesystem [3].
Impact
The primary impact is denial of service (DoS) through repeated allocation failures, as evidenced by kernel log messages such as "Delayed block allocation failed" and "This should not happen!! Data will be lost". This can lead to data loss for files that require block allocation, potentially causing system instability or corruption of user data. The vulnerability does not directly allow arbitrary code execution or privilege escalation [4].
Mitigation
The fix has been applied to the Linux kernel stable tree. Users should update to a kernel version that includes the commit that adds a check for EXT4_MB_GRP_BBITMAP_CORRUPT in ext4_mb_find_by_goal() and returns an error if the group is corrupted, preventing further allocation attempts from that group [1][2][3][4].
AI Insight generated on May 18, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
1Patches
0No patches discovered yet.
Vulnerability mechanics
AI mechanics synthesis has not run for this CVE yet.
References
8- git.kernel.org/stable/c/0b84571c886719823d537f05f4f07cad6357c4b7nvd
- git.kernel.org/stable/c/1895f7904be71c48f1e6f338b28f24dabd6b8aebnvd
- git.kernel.org/stable/c/1c0d7c4cde38a887c6d74e0c89ddb25226943c78nvd
- git.kernel.org/stable/c/2d31a5073f86a177edf44015e0dedb0c47cfd6d8nvd
- git.kernel.org/stable/c/46066e3a06647c5b186cc6334409722622d05c44nvd
- git.kernel.org/stable/c/9370207b36d26e45a8c8ef0500706d37036edd6bnvd
- git.kernel.org/stable/c/fea6b2e250ff48f10d166011b57a8516ae5438c9nvd
- git.kernel.org/stable/c/ffc0a282462d45fee5957621be5afa29752f3b6dnvd
News mentions
0No linked articles in our index yet.