drm/virtio: use the DMA API for resource backing on Xen
CVE-2026-98156 · published 25 Sept 2026
How serious is it
- Severity: high, CVSS score 7.8 out of 10.
- No exploit prediction (EPSS) score yet.
- Not on the CISA list of exploited vulnerabilities.
- No public exploit in Exploit-DB.
Is your app affected by CVE-2026-98156?
Paste this prompt into Claude Code, Cursor or any AI coding tool: it runs a free Shippable scan of your project and fixes what it finds. Built with Lovable, Bolt or v0? Scan your live app. Or upload your package file.
Who is affected
- Linux Linux: a3b815f09bb846255c458c181b8a5b1cc66891b4 to < 32e999ccf5f6453b3b4df8264ff1b03c6720292f, a3b815f09bb846255c458c181b8a5b1cc66891b4 to < 3f130cc6826fabf50e01fe8e4ff3ed1fcae50d36, a3b815f09bb846255c458c181b8a5b1cc66891b4 to < 93c557e947ef0040004b1ac6a1c1265d79a957e1, a3b815f09bb846255c458c181b8a5b1cc66891b4 to < 455184dbe9652d01470d3c5cf5edd09a7a673a99
- Linux Linux: 4.20
How to check
- Find out whether you run the affected product and which version, then compare it with the versions above.
How to fix
Copies a prompt for Claude Code, Cursor or Codex that asks it to check whether you run this product.
- Apply the vendor's update or mitigation from the references below. If there is none yet, limit exposure of the affected service until there is.
- If a vulnerable version was live, check your logs and rotate the secrets that server could read.
The advisory
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.
Check your whole app
Dependencies are only half of it. Free and read-only: before you push, run npx shippable-dev scan localhost:3000 in your project folder, no account needed. For your live app, you prove it's yours with a one-line tag first.
References
- git.kernel.org/stable/c/32e999ccf5f6453b3b4df8264ff1b03c6720292f
- git.kernel.org/stable/c/3f130cc6826fabf50e01fe8e4ff3ed1fcae50d36
- git.kernel.org/stable/c/93c557e947ef0040004b1ac6a1c1265d79a957e1
- git.kernel.org/stable/c/455184dbe9652d01470d3c5cf5edd09a7a673a99
- git.kernel.org/stable/c/6a736d2f9d0c6e6217fe7532bc4c50ceca71db78
Merged from CVE List. Last updated 26 Oct 2026. All vulnerabilities · RSS · JSON