CVE-2026-68145 in Linux
Summary
by MITRE • 08/10/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/10/2026
This vulnerability resides in the Linux kernel's iomap subsystem where improper handling of zero-length memory ranges leads to out-of-bounds memory access through bitmap_set() operations. The flaw manifests in two related functions, ifs_set_range_dirty() and ifs_set_range_uptodate(), which process file system dirty and uptodate state tracking for I/O operations. Both functions calculate the final block index using the formula (off + len - 1) >> i_blkbits where off represents the byte offset and len denotes the length in bytes of the memory range being processed. When the offset is zero and the length parameter equals zero, the unsigned arithmetic underflows causing the calculation to produce an extremely large value of SIZE_MAX, which translates into massive values for last_blk and nr_blks variables.
The operational impact of this vulnerability stems from the fact that bitmap_set() function receives these inflated parameters and attempts to write beyond the allocated memory boundaries of the ifs->state structure. This creates a classic buffer overflow condition that could potentially allow attackers to corrupt adjacent memory regions or even execute arbitrary code through memory corruption. The vulnerability is particularly concerning because it can be triggered during file write operations when copy_folio_from_iter_atomic() returns zero, indicating no data was copied from user space due to faults or other conditions. In such scenarios, the existing guard mechanism in __iomap_write_end() fails to prevent execution flow because the folio is already marked as uptodate, causing iomap_set_range_dirty() to be invoked with a copied value of zero, which represents the exact zero-length range condition that triggers the overflow.
While ifs_set_range_uptodate() appears temporarily safe due to constraints on how len parameter can be passed in, the vulnerability affects both functions due to their similar implementation patterns and shared underlying flaw. The solution involves implementing a simple but critical guard condition checking for zero-length ranges before performing any arithmetic calculations. This approach follows established security principles of input validation and defensive programming that align with CWE-129 and CWE-787 categories, which address issues related to insufficient bounds checking and out-of-bounds memory access. The fix directly addresses the root cause by treating zero-length ranges as no-operations, preventing the arithmetic underflow from occurring while maintaining the expected behavior for valid non-zero length operations.
The vulnerability demonstrates a common class of security flaws in kernel code where assumptions about parameter values lead to unexpected arithmetic behavior. This type of issue falls within ATT&CK framework category TA0005 (Defense Evasion) and TA0004 (Privilege Escalation) when exploited, as successful exploitation could allow unauthorized modification of kernel memory structures. The fix implementation ensures that the code path for zero-length ranges is explicitly handled without triggering the problematic arithmetic sequence, providing a robust solution that maintains system stability while preventing potential security exploits. This vulnerability highlights the importance of rigorous input validation in kernel space programming where even seemingly benign parameter combinations can lead to serious security implications due to the privileged execution context and direct memory access capabilities.