Cloudanix VulnDB

CVE-2026-98156

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Sep 25, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A virtualization graphics driver bug can let the hypervisor read or write the wrong memory pages, potentially leaking data or crashing systems in certain Xen setups.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
High
Impact
Data Exposure
Component
OS kernel
Class
Information Disclosure
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

virtio-gpu driver in Linux kernel skips xen_domain() check when deciding DMA API usage for resource backing, falling back to sg_phys() guest-physical addresses that resolve to unrelated host pages on Xen PV domains, enabling host to access arbitrary memory.

Why it matters to the business

In Xen PV virtualization setups using virtio graphics, this can expose or corrupt memory across domains, risking data leaks, guest isolation failures, and operational instability in cloud or server environments.

How an attack unfolds

An attacker with local privileges on an affected Xen PV guest configures a virtio-vga device without VIRTIO_F_ACCESS_PLATFORM; the guest driver passes sg_phys addresses to the host via virtio_gpu_object_shmem_init, causing QEMU to scan or write pages belonging to other domains when rendering the framebuffer.

How to fix it

Update the Linux kernel to a version containing the fix that moves the xen_domain() check into virtio_gpu_use_dma_api() and enables dma_sync_sgtable_for_device calls; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm kernel source contains the virtio_gpu_use_dma_api() xen_domain() guard and that vring_use_map_api() behavior is mirrored; test on Xen PV dom0 with virtio-vga to verify host no longer receives guest-physical addresses.

Typical attack path

  1. Gain local access to Xen PV guest with virtio-gpu enabled
  2. Trigger framebuffer allocation or display operations without IOMMU platform feature
  3. virtio_gpu_object_shmem_init emits guest-physical SG list to host
  4. Host QEMU performs DMA or scanout using incorrect addresses
  5. Access or modify memory pages of unrelated domains

How to detect it

Review kernel logs for virtio-gpu initialization on Xen PV domains; look for absence of DMA API usage warnings or mismatched address handling during framebuffer setup; correlate with QEMU logs showing unexpected memory access patterns from virtio devices.

What your security team should do

  • Prioritize kernel upgrade on all Xen PV dom0 and guest systems using virtio graphics
  • Disable virtio-vga or switch to PVH dom0 where identity mapping avoids the issue until patched
  • Monitor for upstream stable releases and backports to LTS kernels

The record

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.

Affected packages

Ecosystem Package Introduced Fixed