CVE-2026-43068

In the Linux kernel, the following vulnerability has been resolved:

ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()

Theres 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; // Theres 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.

Weakness

The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.

Affected Software

Potential Mitigations

• Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone.
• For example, glibc in Linux provides protection against free of invalid pointers.
• When using Xcode to target OS X or iOS, enable automatic reference counting (ARC) [REF-391].
• To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std::auto_ptr (defined by ISO/IEC ISO/IEC 14882:2003), std::shared_ptr and std::unique_ptr (specified by an upcoming revision of the C++ standard, informally referred to as C++ 1x), or equivalent solutions such as Boost.

References

• https://git.kernel.org/stable/c/0b84571c886719823d537f05f4f07cad6357c4b7
• https://git.kernel.org/stable/c/1895f7904be71c48f1e6f338b28f24dabd6b8aeb
• https://git.kernel.org/stable/c/1c0d7c4cde38a887c6d74e0c89ddb25226943c78
• https://git.kernel.org/stable/c/2d31a5073f86a177edf44015e0dedb0c47cfd6d8
• https://git.kernel.org/stable/c/46066e3a06647c5b186cc6334409722622d05c44
• https://git.kernel.org/stable/c/9370207b36d26e45a8c8ef0500706d37036edd6b
• https://git.kernel.org/stable/c/fea6b2e250ff48f10d166011b57a8516ae5438c9
• https://git.kernel.org/stable/c/ffc0a282462d45fee5957621be5afa29752f3b6d