CVE-2026-43068: ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid allocate block from corrupted group in ext4mbfindbygoal()
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: ext4mbgeneratebuddy:760 EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4mbgeneratebuddy:760 ...
According to the log analysis, blocks are always requested from the corrupted block group. This may happen as follows: ext4mbfindbygoal ext4mbloadbuddy ext4mbloadbuddygfp ext4mbinitcache ext4readblockbitmapnowait ext4waitblockbitmap ext4validateblockbitmap if (!grp || EXT4MBGRPBBITMAPCORRUPT(grp)) return -EFSCORRUPTED; // There's no logs. if (err) return err; // Will return error ext4lockgroup(ac->acsb, group); if (unlikely(EXT4MBGRPBBITMAPCORRUPT(e4b->bdinfo))) // 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 'EXT4MBGRPBBITMAPCORRUPT(e4b->bdinfo)' is true, then 'ext4mbloadbuddy()' may return an error. This means that the block allocation will fail. Therefore, check block group if corrupted when ext4mbloadbuddy() returns error.
Affected Software
Remediation
Event History
Frequently Asked Questions
What is the severity of CVE-2026-43068?
CVE-2026-43068 has been classified as a moderate severity vulnerability.
How do I fix CVE-2026-43068?
To fix CVE-2026-43068, update the Linux kernel to a version that includes the patch addressing this vulnerability.
What does CVE-2026-43068 affect?
CVE-2026-43068 affects the ext4 filesystem in the Linux kernel.
What are the potential risks of CVE-2026-43068?
The risks of CVE-2026-43068 include the possibility of data corruption and filesystem instability.
Is CVE-2026-43068 a local or remote vulnerability?
CVE-2026-43068 is primarily a local vulnerability that requires access to the affected system.