Skip to main content

Linux Kernel CVE-2026-43068

| EUVDEUVD-2026-27370 MEDIUM
Memory Leak (CWE-401)
2026-05-05 Linux GHSA-pm4x-jf7f-jmq6
Information Disclosure Linux Red Hat Suse
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
SUSE
MEDIUM
qualitative
Red Hat
5.5 LOW
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

3
Analysis Generated
May 20, 2026 - 23:23 vuln.today
CVSS changed
May 20, 2026 - 23:22 NVD
5.5 (MEDIUM)
Patch available
May 05, 2026 - 17:31 EUVD

DescriptionCVE.org

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.

AnalysisAI

Repeated data loss occurs on Linux kernel systems using ext4 filesystems due to the ext4_mb_find_by_goal() function failing to skip corrupted block groups during block allocation. Affected kernels from commit 163a203ddb36 through multiple stable branches will continuously attempt to allocate blocks from a group flagged EXT4_MB_GRP_BBITMAP_CORRUPT, producing kernel error messages stating 'This should not happen!! Data will be lost' and causing permanent inode data loss. No public exploit has been identified and EPSS is 0.02%, but the availability impact is rated High; this is a resilience defect in ext4 error-handling that requires local access and pre-existing filesystem corruption to manifest.

Technical ContextAI

The vulnerability resides in the Linux kernel's ext4 multi-block allocator, specifically in ext4_mb_find_by_goal() (fs/ext4/mballoc.c). When a block bitmap corruption is detected during the call chain ext4_mb_load_buddy_gfp() → ext4_mb_init_cache() → ext4_validate_block_bitmap(), the EXT4_MB_GRP_BBITMAP_CORRUPT flag is set on the block group descriptor and EFSCORRUPTED is returned up the stack. The function ext4_mb_load_buddy() then returns this error to ext4_mb_find_by_goal(), which exits early - making the subsequent guard if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) unreachable. This created a regression: commit 9008a58e5dce changed bitmap read routines to return real error codes, which caused the error exit in ext4_mb_load_buddy() to preempt the corruption check introduced by commit 163a203ddb36, silently restoring the original broken allocation path. The root cause is classified as CWE-401, though the behavior is more precisely an improper exceptional condition propagation (analogous to CWE-754/CWE-755); the CWE-401 label from NVD appears imprecise for this defect. CPE: cpe:2.3:a:linux:linux:*:*:*:*:*:*:*:*.

RemediationAI

Upgrade the Linux kernel to a patched stable version. Vendor-released patches are confirmed available across the following stable branches: 5.10.253, 5.15.203, 6.1.168, 6.6.131, 6.12.80, 6.18.21, 6.19.11, and 7.0. Upstream fix commits are published at https://git.kernel.org/stable/c/fea6b2e250ff48f10d166011b57a8516ae5438c9 (5.10.x), https://git.kernel.org/stable/c/ffc0a282462d45fee5957621be5afa29752f3b6d (5.15.x), https://git.kernel.org/stable/c/2d31a5073f86a177edf44015e0dedb0c47cfd6d8 (6.1.x), https://git.kernel.org/stable/c/0b84571c886719823d537f05f4f07cad6357c4b7 (6.6.x), and others listed in the CVE references. As a compensating control prior to patching, run e2fsck -f /dev/<device> on the affected ext4 partition (offline) to repair corrupted block group bitmaps - this eliminates the prerequisite condition for the bug to trigger; note that fsck requires unmounting the filesystem and may cause brief service interruption. Alternatively, mounting the filesystem read-only via mount -o remount,ro prevents write-triggered allocation paths entirely but disables all write operations. Do not rely on the errors=remount-ro mount option alone, as the corruption detection occurs after the allocation attempt is already underway.

Same weakness CWE-401 – Memory Leak

View all
CVE-2016-4232 HIGH POC
7.5
CVE-2024-25450 HIGH POC
8.8
CVE-2023-33718 HIGH POC
8.8
CVE-2019-6128 HIGH POC
8.8
CVE-2023-34451 HIGH POC
8.2
CVE-2023-41484 HIGH POC
8.1
CVE-2023-23145 HIGH POC
7.8
CVE-2022-35858 HIGH POC
7.8

Same technique Information Disclosure

View all
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8
CVE-2023-7028 CRITICAL POC
10.0
CVE-2017-0213 HIGH POC
7.3

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

CVE-2026-43068 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy