Xen ships three advisories: guest-triggered tapdisk root risk, XPTI break on huge RAM, broken Zenbleed fix

The Xen Project Security Team published three advisories on the same day, covering a high-impact userspace backend flaw, a Meltdown isolation failure on huge-memory x86 hosts, and a regression that left the Zenbleed workaround ineffective on newer Xen releases.

The most severe is XSA-521 (CVE-2026-102701). Tapdisk, the userspace xen-blkback path used by the XAPI toolstack, failed to bound multi-page ring sizes negotiated at connection time and assumed the frontend would not request more than eight pages. A buggy or malicious guest can force a stack overflow in tapdisk. Because tapdisk typically runs as root, that overflow can become host code execution. All tapdisk versions are affected, and the advisory lists no practical mitigation short of the fix. The issue was found by Claude Opus and diagnosed as security-relevant by Teddy Astie of Vates.

XSA-516 (CVE-2026-79609) addresses XPTI, the page-table isolation work introduced against Meltdown. On systems with RAM past the 5 TiB boundary (or 3.5 TiB with the big-memory config), the guest directmap may not cover all physical memory that XPTI needs when copying 64-bit PV root page-table entries. A 64-bit PV guest can elevate to host privilege, snoop other guests, or take the host down. HVM and PVH guests are not in scope; only x86 is affected. Upstream Xen from the late 4.7 through 4.10 stable lines with XPTI backports, and all major releases from 4.11 forward, are vulnerable when that much RAM is present. Operators can avoid 64-bit PV guests or cap hypervisor memory with the mem= command-line limit. George Dunlap reported the issue.

XSA-515 (CVE-2026-79608) corrects an inverted conditional introduced when the Zenbleed (XSA-433 / CVE-2023-20593) MSR workaround was reworked. On Xen 4.19.4 and later minor lines, 4.20.3+, 4.21.1+, and 4.22, the mitigation was applied when it should not have been and skipped when it was required. On AMD Zen 2 systems still running pre-fix microcode, an attacker can read cross-context data on the same core, including key material and AES-NI or memcpy-related contents. Current microcode removes the underlying CPU issue; disabling AVX is a heavy fallback. Sashiko and Opus 5.0 surfaced the bug; Dunlap classified it as a security defect.

Patches for all three advisories are available from the Xen security team. Hosts running XAPI tapdisk, large-memory 64-bit PV workloads, or unpatched Zen 2 silicon without updated microcode should treat the corresponding fixes as priority.