Cloudanix VulnDB

CVE-2026-98242

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug could cause incorrect handling of very large memory transfers between devices, potentially leading to data errors or system problems on affected machines.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Buffer Overflow
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Integer truncation in dma-buf when accumulating size_t lengths into a 32-bit unsigned int mapped_len variable, causing wrap-around and truncated values passed to fill_sg_entry and related SG mapping functions for MMIO regions larger than 4 GB during peer-to-peer DMA.

Why it matters to the business

Linux systems performing large peer-to-peer DMA transfers may experience incorrect memory mappings, leading to data corruption, failed DMA operations, or unpredictable kernel behavior in high-memory server or virtualization workloads.

How an attack unfolds

An attacker with the ability to trigger peer-to-peer DMA operations involving MMIO regions exceeding 4 GB through a host bridge can cause the 32-bit mapped_len variable to silently wrap, resulting in truncated SG lengths that are then used in subsequent DMA setup routines.

How to fix it

Update the Linux kernel to a version containing the dma-buf fix that changes mapped_len to size_t, adopts check_add_overflow for nents, and uses an appropriate loop iterator type; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm the kernel source contains the updated mapped_len declaration as size_t, check_add_overflow usage in calc_sg_nents, and matching unsigned int loop variable in fill_sg_entry; test DMA operations with MMIO sizes exceeding 4 GB.

Typical attack path

  1. Identify or control a device capable of initiating peer-to-peer DMA with MMIO size > 4 GB
  2. Force the dma-buf code path that calculates total linked IOVA through the host bridge
  3. Trigger accumulation into the 32-bit mapped_len variable causing wrap-around
  4. Pass the truncated length to fill_sg_entry or calc_sg_nents
  5. Observe incorrect DMA mappings or subsequent memory access anomalies

How to detect it

Inspect kernel logs for dma-buf or scatter-gather related warnings during large DMA operations; examine source code or running kernel symbols for the pre-fix mapped_len type; no runtime IOCs are derivable from the advisory.

What your security team should do

  • Prioritize kernel updates on systems performing peer-to-peer DMA or hosting large MMIO devices
  • Monitor upstream stable kernel releases for backports of the dma-buf overflow fix
  • Review dma-buf usage in custom drivers or virtualization stacks for similar integer width issues

The record

In the Linux kernel, the following vulnerability has been resolved: dma-buf: Fix silent overflow for phys vec to sgt In case MMIO size is bigger than 4G and peer2peer DMA goes through host bridge, we trigger a code path that assigns the total linked IOVA (which is greater than 4G) to mapped_len. Previously, `mapped_len` was declared as 32-bit `unsigned int`. When accumulating `size_t` lengths, this leads to a silent wrap-around. This truncation causes truncated lengths to be passed to functions like `fill_sg_entry()`. Fix this by changing `mapped_len` to `size_t` (64-bit). While at it, fix similar potential overflow issues in `calc_sg_nents` by using `check_add_overflow()` for `nents` and using `unsigned int` for the loop iterator in `fill_sg_entry` to match.

Affected packages

Ecosystem Package Introduced Fixed