CVE-2026-68145
HighCVSS 7.8Exploitation Probability (EPSS)
Low risk4th percentile - higher than 4% of all known CVEs
Summary
In the Linux kernel's iomap module, the functions ifs_set_range_dirty() and ifs_set_range_uptodate() have an out-of-bounds write vulnerability in bitmap_set() when the range length is zero. An underflow in last_blk calculation leads to huge values, causing a write beyond the allocated memory.
Risk Assessment
The risk includes the possibility of kernel memory corruption, which could lead to system crashes, privilege escalation, or data leakage.
Recommendation
It is recommended to apply the kernel patch that adds a !len check before the calculations, and to update systems.
Original NVD description (English source)
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.