GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel dma-buf: 32-bit mapped_len truncates peer-to-peer DMA mappings larger than 4 GiB

UnscoredCVE-2026-98242Kernel, userspace & hypervisorcurated

Impact

When a peer-to-peer DMA transfer over a MMIO aperture larger than 4 GiB is routed through the host bridge, the total linked IOVA is accumulated into a 32-bit mapped_len, which silently wraps and passes a truncated length into fill_sg_entry(). The scatterlist that comes out does not describe the memory the caller asked to map, and calc_sg_nents() can overflow its nents count as well. This is the code path behind GPU and accelerator peer-to-peer DMA and RDMA-to-GPU transfers - exactly the large BAR mappings on datacenter accelerators - so a mismapped transfer means DMA against the wrong addresses rather than a clean failure. The record describes it as a silent overflow fixed in the stable trees; it does not characterise it as a proven privilege escalation or give a CVSS score.

Who can reach it

Local: a process that can set up a peer-to-peer DMA mapping through dma-buf against a device exposing more than 4 GiB of MMIO - on a GPU node, any tenant holding a GPU device node and using a p2p-capable framework or RDMA path. No remote reach and no authentication beyond device access.

What to do

Take the stable kernel update that widens mapped_len to size_t and adds check_add_overflow() in calc_sg_nents(), then drain and reboot each node. dma-buf is built into the kernel image on server configurations, so there is no module-reload shortcut. The record names only the two stable commits, not a fixed release version.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.