CVE-2026-43068

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()<br /> <br /> There&amp;#39;s issue as follows:<br /> ...<br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): error count since last fsck: 1<br /> EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760<br /> EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760<br /> ...<br /> <br /> According to the log analysis, blocks are always requested from the<br /> corrupted block group. This may happen as follows:<br /> ext4_mb_find_by_goal<br /> ext4_mb_load_buddy<br /> ext4_mb_load_buddy_gfp<br /> ext4_mb_init_cache<br /> ext4_read_block_bitmap_nowait<br /> ext4_wait_block_bitmap<br /> ext4_validate_block_bitmap<br /> if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp))<br /> return -EFSCORRUPTED; // There&amp;#39;s no logs.<br /> if (err)<br /> return err; // Will return error<br /> ext4_lock_group(ac-&gt;ac_sb, group);<br /> if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b-&gt;bd_info))) // Unreachable<br /> goto out;<br /> <br /> After commit 9008a58e5dce ("ext4: make the bitmap read routines return<br /> real error codes") merged, Commit 163a203ddb36 ("ext4: mark block group<br /> as corrupt on block bitmap error") is no real solution for allocating<br /> blocks from corrupted block groups. This is because if<br /> &amp;#39;EXT4_MB_GRP_BBITMAP_CORRUPT(e4b-&gt;bd_info)&amp;#39; is true, then<br /> &amp;#39;ext4_mb_load_buddy()&amp;#39; may return an error. This means that the block<br /> allocation will fail.<br /> Therefore, check block group if corrupted when ext4_mb_load_buddy()<br /> returns error.