Xen publishes XSA-510 through XSA-513 (v3): four advisories covering hypervisor crashes, data exposure, oxenstored resource exhaustion, and Tapdisk out-of-bounds flaws

Xen's x86 hypervisor improperly handles return codes in its HVM instruction emulation path, and a guest that has been assigned a PCI device (via passthrough) whose BAR (Base Address Register) is mapped into the I/O port address space can trigger a BUG() in the hypervisor, as documented in Xen Security Advisory 510 (CVE-2026-79602). An attacker controlling such a guest — typically a guest administrator on a host using PCI device assignment — can deliberately trigger the flaw through guest actions that go through the emulation path. The outcome is a denial of service: the BUG() crashes the host's hypervisor, disrupting all guests on that physical machine; the advisory does not indicate privilege escalation or data exposure. Only x86 Xen deployments that assign PCI devices to guests where an assigned device has an I/O port BAR are affected; hosts without passthrough, or with MMIO-only devices, are not exposed. There is no public proof-of-concept, the issue is not in CISA KEV, and EPSS estimates only a 0.2% 30-day exploitation probability (7th percentile), so no exploitation is currently known.

Do: Update the Xen hypervisor per XSA-510 v3 (consult the advisory for the fixed version ranges applicable to your supported release), scheduling host reboots as required. Until patched, audit guest configurations for PCI device passthrough (e.g., 'xl pci-list' and guest device assignments), identify assigned devices with I/O port BARs using 'lspci -v', and avoid assigning such devices to guests or limit those guests to trusted administrators. Since the impact is a guest-triggered host crash, prioritizing patching on hosts that use device assignment is the most efficient remediation path.

This is a memory-management flaw in the Xen hypervisor on x86 systems: a paravirtualized (PV) guest can free a memory page while a stale TLB (translation lookaside buffer) entry pointing to that page still exists, and Xen only issues a TLB flush, if needed, when the page is later re-used. Because the freed page can be scrubbed (zeroed) ahead of that deferred TLB flush, a window exists in which the guest can write to a page that has already been scrubbed, potentially corrupting or tainting memory Xen believes is clean. The practical impact, per the CVSS 3.1 score of 4.3 (medium, confidentiality impact only), is limited information exposure rather than privilege escalation or denial of service. Only operators of Xen hypervisors on x86 hardware that run PV guests are affected. Exploitation status is calm: there is no public proof-of-concept, the flaw is not in CISA's KEV catalog, and EPSS puts 30-day exploitation probability at just 0.2% (14th percentile).

Do: Upgrade Xen to a patched release per the version table in Xen Security Advisory 511 v3, which fixes the issue by unconditionally performing TLB flushing ahead of page scrubbing. Prioritize hosts running untrusted or multi-tenant PV guests, and consult the advisory for any interim workarounds if patching must be deferred. Administrators can also reduce exposure by migrating workloads from PV to HVM/PVH guest modes, which are not affected by this x86 PV-specific flaw.