High [CVE-2026-68145] fix out-of-bounds bitmap_set with zero-length range

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. An unsigned subtraction underflow occurs when `ifs_set_range_dirty()` or `ifs_set_range_uptodate()` are called with a zero-length range.

This can lead to an out-of-bounds write via `bitmap_set()`, potentially allowing a local attacker to cause memory corruption or a denial of service. Red Hat severity: Important — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H).

Weakness: CWE-787.