Skip to main content
VulnerabilityPublished Updated

CVE-2026-68145: Linux kernel · iomap: fix out-of-bounds bitmap_set() with zero-length range

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 7.8 High · fixed in fb4fad9105c88b1d82f1b3c39e3b6abea8249af6 : patch Linux kernel soon.

Data as of 26 Oct 2026, 17:30 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 3% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in fb4fad9105c88b1d82f1b3c39e3b6abea8249af6, c5b6a48a8a716a7730e39af1cad083dc4ec955ce, 48829622212f6b8f49155889aecc818ba28ba680 +2
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 10 Aug 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 4ce02c67972211be488408c275c8fbf19faf29b3, < fb4fad9105c88b1d82f1b3c39e3b6abea8249af6
Fixed in
  • fb4fad9105c88b1d82f1b3c39e3b6abea8249af6
LinuxLinuxAffected
  • ≥ 4ce02c67972211be488408c275c8fbf19faf29b3, < c5b6a48a8a716a7730e39af1cad083dc4ec955ce
Fixed in
  • c5b6a48a8a716a7730e39af1cad083dc4ec955ce
LinuxLinuxAffected
  • ≥ 4ce02c67972211be488408c275c8fbf19faf29b3, < 48829622212f6b8f49155889aecc818ba28ba680
Fixed in
  • 48829622212f6b8f49155889aecc818ba28ba680
LinuxLinuxAffected
  • ≥ 4ce02c67972211be488408c275c8fbf19faf29b3, < 7037e7bdcd26f46c080b8ce307dee5cb471c4b7c
Fixed in
  • 7037e7bdcd26f46c080b8ce307dee5cb471c4b7c
LinuxLinuxAffected
  • ≥ 4ce02c67972211be488408c275c8fbf19faf29b3, < 9c7d8f7c8994c790fca501dc45ce66e7356cbe05
Fixed in
  • 9c7d8f7c8994c790fca501dc45ce66e7356cbe05
LinuxLinuxAffected
  • =6.6
Fixed in–

Description

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.

References

Community reviews

Loading reviews…