Scheduled maintenance: Some features related to account registration and licensing may be temporarily unavailable from Friday (May 8) at 1 PM to Sunday (May 10) at 5 PM (PST).
HomeDefectsLIN1023-22830
Fixed

LIN1023-22830 : Security Advisory - linux - CVE-2026-43068

Created: May 5, 2026    Updated: May 7, 2026
Resolved Date: May 6, 2026
Found In Version: 10.23.30.2
Fix Version: 10.23.30.21
Severity: Standard
Applicable for: Wind River Linux LTS 23
Component/s: Kernel

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.