CVE-2026-68145

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