Linux Kernel CVE-2026-98156

Requires the guest to run as a Xen PV domain (PVH and HVM/identity-mapped domains are NOT affected because their guest-physical addresses map correctly). It further requires the virtio-gpu/virtio-vga device to be in use where the host has NOT negotiated VIRTIO_F_ACCESS_PLATFORM (e.g. QEMU's default virtio-vga, which does not set iommu_platform), so the driver's use_dma_api stays false and framebuffer backing is described with raw guest-physical addresses. Limiting factors: local access as the guest kernel (PR:L), the specific Xen PV deployment mode, the absence of iommu_platform/ACCESS_PLATFORM negotiation, and the presence of virtio-gpu - all making this a non-default, higher-complexity condition (AC:H) rather than a remotely reachable flaw.

This is a niche isolation/correctness bug in the Linux kernel drm/virtio-gpu driver that only manifests on Xen PV domains. The provided CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H, base 7.8) correctly captures the LOCAL, higher-complexity, low-privilege nature: it requires the guest to be running as a Xen PV domain (PVH domains are identity-mapped and unaffected) with virtio-gpu/virtio-vga where the host did not negotiate VIRTIO_F_ACCESS_PLATFORM. There is no EPSS score, no CISA KEV listing, and no public exploit - so exploitation status is 'no public exploit identified at time of analysis.' Unlike much of the DoS-mislabeled Linux 'Information Disclosure' catalog, the confidentiality impact here is DEFENSIBLE: because the guest describes its framebuffer backing with guest-physical addresses, the Xen host resolves them to pages belonging to OTHER domains and scans out that unrelated memory to the guest's display - a genuine cross-domain confidentiality leak crossing an isolation boundary (justifying S:C/C:H). However, this is not an attacker-crafted exploit primitive; it is a passive misconfiguration inherent to running virtio-gpu under Xen PV. Integrity/availability impact (I:H/A:H) appears OVERSTATED - the observed behavior is memory disclosure, with at most incidental corruption. Net real-world priority is LOW: the vulnerable configuration (Xen PV dom0 + virtio-vga, often nested in QEMU) is uncommon, and there is no evidence of exploitation.

A guest kernel runs as a Xen PV domain (e.g. a PV dom0) using virtio-gpu/virtio-vga where QEMU has not enabled iommu_platform, so the driver keeps use_dma_api false and hands guest-physical framebuffer addresses to the host. The host resolves those addresses to machine pages belonging to a different Xen domain and scans that memory out to the affected guest's display, disclosing another domain's memory across the isolation boundary. No public exploit code exists; the condition was reproduced by researchers with Xen 4.21 PV dom0 nested in QEMU 8.2 on 6.8 and 6.18 LTS kernels.