Answer in brief
CVE-2026-43068 records a Unknown severity vulnerability in ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | 3.12 | Not reported |
| Linux/Linuxgeneric | >=163a203ddb36c36d4a1c942aececda0cc8d06aa7 <fea6b2e250ff48f10d166011b57a8516ae5438c9 || >=163a203ddb36c36d4a1c942aececda0cc8d06aa7 <0b84571c886719823d537f05f4f07cad6357c4b7 || >=163a203ddb36c36d4a1c942aececda0cc8d06aa7 <ffc0a282462d45fee5957621be5afa29752f3b6d || >=163a203ddb36c36d4a1c942aececda0cc8d06aa7 <2d31a5073f86a177edf44015e0dedb0c47cfd6d8 || >=163a203ddb36c36d4a1c942aececda0cc8d06aa7 <9370207b36d26e45a8c8ef0500706d37036edd6b || >=163a203ddb36c36d4a1c942aececda0cc8d06aa7 <1895f7904be71c48f1e6f338b28f24dabd6b8aeb || >=163a203ddb36c36d4a1c942aececda0cc8d06aa7 <1c0d7c4cde38a887c6d74e0c89ddb25226943c78 || >=163a203ddb36c36d4a1c942aececda0cc8d06aa7 <46066e3a06647c5b186cc6334409722622d05c44 | fea6b2e250ff48f10d166011b57a8516ae5438c9, 0b84571c886719823d537f05f4f07cad6357c4b7, ffc0a282462d45fee5957621be5afa29752f3b6d, 2d31a5073f86a177edf44015e0dedb0c47cfd6d8, 9370207b36d26e45a8c8ef0500706d37036edd6b, 1895f7904be71c48f1e6f338b28f24dabd6b8aeb, 1c0d7c4cde38a887c6d74e0c89ddb25226943c78, 46066e3a06647c5b186cc6334409722622d05c44 |
Published upstream
May 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Nov 6, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Nov 6, 2026
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.
Quoted source text, attributed separately from HOL analysis.