Xen Project publishes five security advisories (XSA-509 through XSA-513) covering six CVEs in the x86 hypervisor, oxenstored, and Tapdisk

CVE-2026-62437 is a memory leak in the Xen hypervisor on x86 systems involving tracking structures for IRQs used by PCI devices assigned to guests. When a guest is terminated, cleanup of assigned PCI devices and their IRQ tracking normally happens early, but the guest's device model (DM) can re-establish that tracking by binding one or more IRQs anew after cleanup has run, and at least one of those re-created structures is never freed. An attacker who controls a guest with assigned PCI devices could repeatedly terminate guests (or trigger re-binding before termination) to steadily consume host memory, ultimately degrading or DoS-ing the host. Only Xen deployments on x86 that use PCI device passthrough with a device model are affected; operators not using passthrough are not exposed. There is no public proof-of-concept, the issue is not in CISA KEV, EPSS is 0.2% (7th percentile), and no exploitation is known.

Do: Check whether any x86 Xen hosts assign PCI devices to guests (passthrough, e.g. GPU or SR-IOV NIC assignment); if none do, you are not exposed. For affected hosts, update the hypervisor to a build containing the XSA-509 fix per the advisory's listed patched versions, and as an interim measure restrict passthrough to trusted guests and monitor/restart hosts to reclaim leaked memory.

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.