Xen grant-table double version-change race enabling host privilege escalation
CVE-2026-79610 is a race condition in Xen grant-table handling, tracked as XSA-517. Changing a grant table from version 2 to version 1 frees its status pages; changing it back to version 2 reallocates those pages, potentially at different addresses. Concurrent grant-table operations can consequently retain stale pointers into the status array and access freed or repurposed memory. This case was not addressed by the earlier transition-race fixes in XSA-501. Xen versions 4.0 onward are affected when grant-table version 2 is available to multi-vCPU x86 guests. Successful exploitation may permit host privilege escalation, information disclosure, or denial of service.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
A malicious guest may breach the guest-to-hypervisor security boundary and gain host-level privileges. Exploitation can also disclose information or crash the host, disrupting hosted workloads. XenServer 8.4 and 9 are affected. Arm guests, single-vCPU guests, and Xen builds without grant-table support are not exposed to this vulnerability.
If you can’t patch tonight, do this now.
Restrict grant tables to version 1 using the hypervisor command-line option "gnttab=max-ver:1", or set "max_grant_version=1" for each potentially hostile guest. Xen 4.13 and newer builds with CONFIG_GRANT_TABLE disabled are not vulnerable.
Patch, then assume compromise.
Apply the applicable Xen XSA-517 patch or install vendor packages incorporating the fix. Downstream maintainers should update to the tip of the relevant stable branch before applying the upstream patch. For Debian 13 (trixie), upgrade Xen packages to 4.20.4+39-gf1e1321c87-0+deb13u1 or later. For XenServer 8.4 and 9, install the latest applicable updates from the Normal or Early Access channel under CTX697170. For SUSE and Fedora deployments, install the corresponding distribution Xen security updates. XenServer updates do not change the reported product version, so that version alone cannot establish whether the fix is installed.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
19 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.