CVE-2026-43068
Awaiting Analysis Awaiting Analysis - Queue
Buffer Overflow in Linux Kernel ext4 Filesystem

Publication date: 2026-05-05

Last updated on: 2026-05-05

Assigner: kernel.org

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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-05
Last Modified
2026-05-05
Generated
2026-05-07
AI Q&A
2026-05-05
EPSS Evaluated
N/A
NVD
CVE-2026-43068
EUVD
EUVD-2026-27370
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
linux kernel *
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's ext4 filesystem, specifically in the block allocation process. The issue occurs when the system tries to allocate blocks from a corrupted block group in the ext4_mb_find_by_goal() function. Due to improper handling of corrupted block groups, the filesystem may attempt to allocate blocks from these corrupted groups, leading to delayed block allocation failures and data loss.

The problem arises because the code does not properly check for corrupted block groups after ext4_mb_load_buddy() returns an error, allowing block allocation to fail and causing filesystem errors.


How can this vulnerability impact me? :

This vulnerability can lead to data loss due to failed block allocations in the ext4 filesystem. When the filesystem tries to allocate blocks from corrupted block groups, it results in errors such as 'Delayed block allocation failed' and messages indicating that data will be lost.

Such failures can cause filesystem instability, potential corruption, and loss of important data stored on affected partitions.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring system logs for specific EXT4 filesystem error messages indicating delayed block allocation failures and corrupted block groups.

  • Look for log entries similar to: "EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode ... with error 117" and "EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost".
  • Check for error counts and timestamps in EXT4-fs logs, such as "error count since last fsck" and errors related to "ext4_mb_generate_buddy".

Commands to help detect these issues include checking the kernel logs with:

  • dmesg | grep EXT4-fs
  • journalctl -k | grep EXT4-fs
  • grep EXT4-fs /var/log/syslog

Additionally, running filesystem checks (fsck) on the affected partitions may reveal corrupted block groups.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves preventing data loss caused by corrupted block groups in the EXT4 filesystem.

  • Run a filesystem check (fsck) on the affected EXT4 partitions to detect and repair corrupted block groups.
  • Avoid using the affected block groups by ensuring the filesystem is repaired and healthy before further use.
  • Update the Linux kernel to a version that includes the fix for this vulnerability, which avoids allocating blocks from corrupted groups.

Regularly monitor system logs for EXT4 errors to detect any recurrence early.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart