Overview
About vulnerability
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.
Details
- Affected product:
- AlmaLinux 9.2 ESU , Debian 10 ELS , TuxCare 9.6 ESU , TuxCare 9.8 ESU
- Affected packages:
- linux @ 4.19.0 (+3 more)
Fixes
KernelCare state
Live-patch status from KernelCare for each operating system.
| Operating system | Status | Covered kernels |
|---|---|---|
| AlmaLinux 10 | Released |
62 kernels
|
| AlmaLinux 9 | Released |
95 kernels
|
| AlmaLinux 9.6 ESU | Planned | — |
| Debian 13 | Planned | — |
| Oracle Linux 10 | Released |
48 kernels
|
| Oracle Linux 9 | Released |
88 kernels
|
| RHEL 10 | Released |
62 kernels
|
| RHEL 9 | Released |
93 kernels
|
| Rocky Linux 10 | Released |
45 kernels
|
| Rocky Linux 9 | Released |
70 kernels
|
| Ubuntu 24.04 | Planned | — |
| Ubuntu 24.04 AWS | Planned | — |
| Ubuntu 26.04 | Will Not Fix | — |