CVE-2026-23558

Vulnerability

A race window remains in Xen's grant table version change logic even after the fixes for XSA-379 and XSA-387. When a HVM or PVH guest concurrently performs a grant table version change from v2 to v1 and maps status pages via XENMEM_add_to_physmap, some status pages can be freed while mappings of those pages are still being inserted into the guest's secondary (P2M) page tables [1][2]. All Xen versions from 4.0 onward are affected; versions 3.4 and older are not affected [2]. Only x86 HVM and PVH guests permitted to use grant table version 2 interfaces can trigger the issue; x86 PV guests cannot, and Arm does not support grant table v2 [2].

Exploitation

An attacker must have access to a x86 HVM or PVH guest that is allowed to use grant table version 2 interfaces. The attacker initiates a grant table version change from v2 to v1 in parallel with mapping the status pages via XENMEM_add_to_physmap. The race window allows the status pages to be freed while their mappings are still being inserted into the guest's P2M page tables [1][2]. No additional authentication or special privileges within the guest are required beyond the ability to perform these operations.

Impact

Successful exploitation can lead to privilege escalation, information leaks, and denial of service (DoS) that may affect the entire host system [2]. The compromise is not limited to the guest; the freed status pages with stale P2M mappings can be leveraged to gain elevated privileges or leak sensitive data from the host or other guests [2].

Mitigation

Patches are available in the official Xen Security Advisory XSA-486 [2]. System administrators can apply the provided patch (e.g., xsa486.patch) to resolve the issue [2]. As a workaround, using the hypervisor command-line option gnttab=max-ver:1 or setting the guest configuration option max_grant_version=1 for HVM and PVH guests will avoid the vulnerability by preventing use of grant table version 2 [2]. No KEV listing or EOL status is indicated in the references.