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

ext4: handle wraparound when searching for blocks for indirect mapped blocks

Commit 4865c768b563 ("ext4: always allocate blocks only from groups
inode can use") restricts what blocks will be allocated for indirect
block based files to block numbers that fit within 32-bit block
numbers.

However, when using a review bot running on the latest Gemini LLM to
check this commit when backporting into an LTS based kernel, it raised
this concern:

If ac->ac_g_ex.fe_group is >= ngroups (for instance, if the goal
group was populated via stream allocation from s_mb_last_groups),
then start will be >= ngroups.

Does this allow allocating blocks beyond the 32-bit limit for
indirect block mapped files? The commit message mentions that
ext4_mb_scan_groups_linear() takes care to not select unsupported
groups. However, its loop uses group = *start, and the very first
iteration will call ext4_mb_scan_group() with this unsupported
group because next_linear_group() is only called at the end of the
iteration.

After reviewing the code paths involved and considering the LLM
review, I determined that this can happen when there is a file system
where some files/directories are extent-mapped and others are
indirect-block mapped. To address this, add a safety clamp in
ext4_mb_scan_groups().
Published: 2026-05-05
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel contains a logic flaw that allows the allocation of indirect block files beyond the 32‑bit block number limit under certain conditions involving mixed extent‑mapped and indirect‑mapped files. This can lead to wraparound of block numbers, causing malformed metadata and potentially corrupting file system data. The vulnerability is a result of improper bounds checking in block allocation routines, which may compromise data integrity on affected systems.

Affected Systems

All Linux kernel versions that use ext4 prior to the inclusion of the safety clamp in ext4_mb_scan_groups(). The exact affected kernel releases are not listed, but any version with the flawed allocation logic is susceptible unless the patch has been applied.

Risk and Exploitability

The potential exploitation of this issue requires the ability to create or manipulate an ext4 file system that mixes extent‑mapped and indirect‑mapped objects. While no EPSS score is available and the vulnerability is not listed in CISA KEV, the logic flaw has the capacity to corrupt data and could be leveraged by an attacker with sufficient local access to the target system. The lack of publicly available exploitation evidence suggests a moderate to high risk for environments that cannot be updated promptly.

Generated by OpenCVE AI on May 5, 2026 at 17:52 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade to a Linux kernel version that includes the safety clamp in ext4_mb_scan_groups() to restrict block allocations to the 32‑bit limit
  • Run a full consistency check on all ext4 partitions with e2fsck to detect any potential corruption after the upgrade
  • If an upgrade cannot be performed immediately, restrict write access to ext4 file systems or migrate critical workloads to alternative file system types until the patch is applied

Generated by OpenCVE AI on May 5, 2026 at 17:52 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Tue, 05 May 2026 18:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-190

Tue, 05 May 2026 16:15:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: ext4: handle wraparound when searching for blocks for indirect mapped blocks Commit 4865c768b563 ("ext4: always allocate blocks only from groups inode can use") restricts what blocks will be allocated for indirect block based files to block numbers that fit within 32-bit block numbers. However, when using a review bot running on the latest Gemini LLM to check this commit when backporting into an LTS based kernel, it raised this concern: If ac->ac_g_ex.fe_group is >= ngroups (for instance, if the goal group was populated via stream allocation from s_mb_last_groups), then start will be >= ngroups. Does this allow allocating blocks beyond the 32-bit limit for indirect block mapped files? The commit message mentions that ext4_mb_scan_groups_linear() takes care to not select unsupported groups. However, its loop uses group = *start, and the very first iteration will call ext4_mb_scan_group() with this unsupported group because next_linear_group() is only called at the end of the iteration. After reviewing the code paths involved and considering the LLM review, I determined that this can happen when there is a file system where some files/directories are extent-mapped and others are indirect-block mapped. To address this, add a safety clamp in ext4_mb_scan_groups().
Title ext4: handle wraparound when searching for blocks for indirect mapped blocks
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-05T15:23:26.717Z

Reserved: 2026-05-01T14:12:55.981Z

Link: CVE-2026-43067

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-05-05T16:16:15.937

Modified: 2026-05-05T16:16:15.937

Link: CVE-2026-43067

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-05-05T18:00:13Z

Weaknesses