Out-of-bounds Write Affecting kernel-rt-64k-debug-modules package, versions *


Severity

Recommended
0.0
high
0
10

Based on Red Hat Enterprise Linux security rating.

Threat Intelligence

EPSS
0.14% (4th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-RHEL10-KERNELRT64KDEBUGMODULES-18663196
  • published12 Aug 2026
  • disclosed10 Aug 2026

Introduced: 10 Aug 2026

NewCVE-2026-68145  (opens in a new tab)
CWE-787  (opens in a new tab)

How to fix?

There is no fixed version for RHEL:10 kernel-rt-64k-debug-modules.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-rt-64k-debug-modules package and not the kernel-rt-64k-debug-modules package as distributed by RHEL. See How to fix? for RHEL:10 relevant fixed versions and status.

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.

CVSS Base Scores

version 3.1