Cloudanix VulnDB

CVE-2026-68145

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux kernel can let a program running on the computer corrupt memory and potentially crash the system or gain elevated access.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Out-of-bounds write via bitmap_set() caused by unsigned integer underflow when computing last_blk from a zero-length range (off=0, len=0) in ifs_set_range_dirty(), corrupting memory beyond the iomap state allocation.

Why it matters to the business

Local memory corruption in the kernel can lead to system crashes, data loss, or full host compromise on affected Red Hat systems; low but non-zero exploitation probability means prioritized patching is required to avoid operational disruption.

How an attack unfolds

A local attacker triggers a write path in which copy_folio_from_iter_atomic() returns zero bytes (for example via a user-buffer fault) on an already-uptodate folio, bypassing the uptodate guard and reaching iomap_set_range_dirty() with a zero-length range that underflows and performs an unbounded bitmap_set().

How to fix it

Upgrade Red Hat Enterprise Linux kernels to the fixed releases: kernel (redhat el10) 6.12.0-211.51.1.el10_2 or kernel (redhat el9) 5.14.0-687.44.1.el9_8 as supplied in RHSA-2026:63128.

How to confirm the fix worked

Verify running kernel version matches or exceeds the listed fixed releases; confirm the !len guard is present in ifs_set_range_dirty() and ifs_set_range_uptodate() via source inspection or kpatch status.

Typical attack path

  1. Cause a user-space buffer fault during a buffered write
  2. Enter __iomap_write_end() with copied==0 on an uptodate folio
  3. Invoke ifs_set_range_dirty() with len==0
  4. Trigger underflow of last_blk to SIZE_MAX
  5. Execute bitmap_set() far beyond allocated state memory

How to detect it

Examine kernel logs for oops or panic messages referencing iomap, bitmap_set, or ifs_set_range_dirty; no public exploitation artifacts are known at this time.

What your security team should do

  • Apply the referenced Red Hat kernel updates within the next maintenance window
  • Restrict untrusted local code execution on systems that cannot be immediately updated
  • Monitor vendor advisories for any back-port releases to older kernels

The record

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.

Affected packages

Ecosystem Package Introduced Fixed