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: 9.8 Critical
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

Based on the description, the vulnerability is a logic flaw that allows the ext4 file system to allocate blocks beyond the 32‑bit block number limit when handling indirect‑mapped files in a mixed extent/indirect environment. The flaw stems from an oversight in the ext4_mb_scan_groups() routine, where an unsupported group may be selected, resulting in wraparound of block numbers and potentially corrupting file system metadata. The potential impact is data corruption or loss on the affected partitions.

Affected Systems

The affected platforms are Linux systems running any kernel that contains the ext4 file system with the flawed allocation logic prior to the addition of the safety clamp in ext4_mb_scan_groups(). The CPE data indicates that copies of the Linux kernel, any version without the fix, are vulnerable. No specific distribution names are disclosed, so perform a kernel version audit to identify vulnerable systems.

Risk and Exploitability

The CVSS score is 9.8, indicating a high severity. The EPSS score is less than 1%, suggesting a low likelihood of exploitation. The vulnerability is not included in the CISA KEV catalog. Based on the description, the likely attack vector requires local write access to an ext4 file system or the ability to create a mixed extent/indirect file system, which would allow an attacker to trigger the allocation error and potentially corrupt the data.

Generated by OpenCVE AI on May 21, 2026 at 00:51 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that includes the safety clamp in ext4_mb_scan_groups() to restrict block allocations to the 32‑bit limit.
  • After upgrading, run a full file system check with e2fsck on all ext4 partitions to identify any corruption caused by prior allocation errors.
  • Until an upgrade is possible, restrict write access to ext4 file systems for non‑trusted users or consider migrating critical workloads to a different file system that does not use the vulnerable allocation logic.

Generated by OpenCVE AI on May 21, 2026 at 00:51 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 20 May 2026 23:30:00 +0000

Type Values Removed Values Added
Weaknesses NVD-CWE-noinfo
CPEs cpe:2.3:o:linux:linux_kernel:6.1.167:*:*:*:*:*:*:*

Fri, 08 May 2026 13:00:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

cvssV3_1

{'score': 9.8, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}


Wed, 06 May 2026 12:15:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate


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-23T16:06:13.105Z

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

Link: CVE-2026-43067

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

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

Modified: 2026-05-20T23:16:20.980

Link: CVE-2026-43067

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-05-05T00:00:00Z

Links: CVE-2026-43067 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-21T01:00:16Z

Weaknesses