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.
Product status
163a203ddb36c36d4a1c942aececda0cc8d06aa7 (git) before fea6b2e250ff48f10d166011b57a8516ae5438c9
163a203ddb36c36d4a1c942aececda0cc8d06aa7 (git) before 0b84571c886719823d537f05f4f07cad6357c4b7
163a203ddb36c36d4a1c942aececda0cc8d06aa7 (git) before ffc0a282462d45fee5957621be5afa29752f3b6d
163a203ddb36c36d4a1c942aececda0cc8d06aa7 (git) before 2d31a5073f86a177edf44015e0dedb0c47cfd6d8
163a203ddb36c36d4a1c942aececda0cc8d06aa7 (git) before 9370207b36d26e45a8c8ef0500706d37036edd6b
163a203ddb36c36d4a1c942aececda0cc8d06aa7 (git) before 1895f7904be71c48f1e6f338b28f24dabd6b8aeb
163a203ddb36c36d4a1c942aececda0cc8d06aa7 (git) before 1c0d7c4cde38a887c6d74e0c89ddb25226943c78
163a203ddb36c36d4a1c942aececda0cc8d06aa7 (git) before 46066e3a06647c5b186cc6334409722622d05c44
3.12
Any version before 3.12
5.10.253 (semver)
5.15.203 (semver)
6.1.168 (semver)
6.6.131 (semver)
6.12.80 (semver)
6.18.21 (semver)
6.19.11 (semver)
7.0 (original_commit_for_fix)
References
git.kernel.org/...c/fea6b2e250ff48f10d166011b57a8516ae5438c9
git.kernel.org/...c/0b84571c886719823d537f05f4f07cad6357c4b7
git.kernel.org/...c/ffc0a282462d45fee5957621be5afa29752f3b6d
git.kernel.org/...c/2d31a5073f86a177edf44015e0dedb0c47cfd6d8
git.kernel.org/...c/9370207b36d26e45a8c8ef0500706d37036edd6b
git.kernel.org/...c/1895f7904be71c48f1e6f338b28f24dabd6b8aeb
git.kernel.org/...c/1c0d7c4cde38a887c6d74e0c89ddb25226943c78
git.kernel.org/...c/46066e3a06647c5b186cc6334409722622d05c44