CVE-2026-98156: drm/virtio: use the DMA API for resource backing on Xen
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. virtioring.c handles this correctly, vringusemapapi() returns true for any xendomain() regardless of VIRTIOFACCESSPLATFORM.
virtio-gpu makes the same decision independently, but its copy looks only at the feature bit:
bool usedmaapi = !virtiohasdmaquirk(vgdev->vdev);
QEMU does not set iommuplatform on virtio-vga by default, so VIRTIOFACCESSPLATFORM is not negotiated, usedmaapi is false, and virtiogpuobjectshmeminit() describes the framebuffer's backing pages to the host with sgphys(). 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 virtiogpuusedmaapi() and give it the xendomain() check, like vringusemapapi() has. This additionally enables the dmasyncsgtablefordevice() calls in virtgpuvq.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.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The issue affects Linux kernel systems using virtio-gpu in a Xen PV domain. It is specifically relevant when the guest's framebuffer backing pages are provided to the host using guest-physical addresses rather than DMA-mapped addresses.
Is the default QEMU virtio-vga configuration affected?
Yes. QEMU does not enable iommu_platform on virtio-vga by default, so VIRTIO_F_ACCESS_PLATFORM is not negotiated; the prior virtio-gpu logic could therefore avoid the DMA API even in a Xen PV domain.
What is the observable impact on an affected guest?
The host can resolve the supplied guest-physical framebuffer addresses to pages belonging to another domain and scan out unrelated memory. This can result in display output containing memory that does not belong to the affected guest.
What changes in the resolved kernel behavior?
The DMA API decision now includes a Xen PV domain check, matching virtio ring handling. This causes framebuffer backing resources to use DMA mappings and enables required DMA synchronization when swiotlb is in use.