CVE-2026-43067: ext4: handle wraparound when searching for blocks for indirect mapped blocks
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().
Security readout for executives and security teams
Plain-English summary
A Linux ext4 allocation flaw can select blocks beyond the addressing limit of older indirect-mapped files. It requires a filesystem mixing extent-mapped and indirect-block-mapped objects. The supplied record assigns CVSS 9.8, but does not establish practical remote reachability, confirmed attacks, or precise business impact.
Executive priority
Prioritize verification and planned kernel remediation because filesystem integrity and availability may be at risk. Escalate systems with matching ext4 conditions, but avoid declaring an active internet emergency: the supplied evidence shows no exploitation and does not substantiate the network vector.
Technical view
The ext4 multiblock allocator may begin a linear group scan with a group at or beyond the permitted range. Its first scan can therefore bypass the intended 32-bit block-number restriction for indirect-mapped files. The correction adds a safety clamp in ext4_mb_scan_groups().
Likely exposure
Potential exposure is limited to Linux systems running a vulnerable kernel or backport and using ext4 filesystems containing both extent-mapped and indirect-block-mapped files. The bundle does not provide sufficiently explicit affected ranges; compare deployed vendor builds against the referenced stable commits.
Exploitation context
The bundle marks this CVE as absent from KEV and provides no evidence of active exploitation or a public exploit. Although the supplied vector claims unauthenticated network attackability, the description documents an ext4 allocation condition without explaining a remote trigger path. Treat real-world exploitability as unconfirmed.
Researcher notes
The triggering path involves ac_g_ex.fe_group reaching or exceeding ngroups before ext4_mb_scan_groups_linear() performs its first scan. Mixed extent and indirect mappings are explicitly required. The source bundle omits a clear vulnerable-version range, trigger provenance, demonstrated impact, and exploitation analysis; downstream backports require commit-level review.
Mitigation direction
Install a vendor kernel update that incorporates the applicable stable correction.
Compare custom or backported kernels with the six referenced Linux stable commits.
Prioritize systems using ext4 filesystems with mixed mapping formats.
Follow distribution guidance where package versions differ from upstream kernel versions.
Validation and detection
Inventory kernel and distribution package versions on systems mounting ext4 filesystems.
Determine whether applicable kernels contain the ext4 safety-clamp correction.
Identify ext4 environments containing both extent-mapped and indirect-block-mapped files.
Review kernel and filesystem logs for ext4 allocation errors or corruption indicators.
Confirm patched systems boot successfully and ext4 filesystems remain operational.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-43067 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
7Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.