Linux Kernel EUVD-2026-55529

The Linux kernel iomap subsystem (cpe:2.3:a:linux:linux) provides a generic block-mapping layer consumed by filesystems such as ext4, XFS, and btrfs. The in-folio state (ifs) structure tracks dirty and uptodate ranges via per-block bitmaps allocated at folio attachment time. ifs_set_range_dirty() and ifs_set_range_uptodate() both compute the final block index as last_blk = (off + len - 1) >> i_blkbits and the count as nr_blks = last_blk - first_blk + 1. When len is zero and off is zero, the subtraction of 1 from an unsigned size_t value underflows to SIZE_MAX, yielding a last_blk and nr_blks that are effectively unlimited, which causes the subsequent bitmap_set() call to write many bytes beyond the end of the ifs->state allocation - a classic heap out-of-bounds write. Although ifs_set_range_uptodate() cannot currently be reached with len0 because its callers enforce non-zero lengths, ifs_set_range_dirty() is reachable via __iomap_write_end() when copy_folio_from_iter_atomic() returns 0 (triggered by a faulting user-space buffer) while the target folio is already uptodate - a combination that skips the early-exit guard (!folio_test_uptodate() is false) and passes copied0 directly into iomap_set_range_dirty(). The root cause is an absent zero-length guard, addressed by the upstream fix which makes both functions no-ops when len is zero. CWE is not formally assigned by NVD, but the vulnerability class is an integer underflow leading to an out-of-bounds write (CWE-191 / CWE-787).