CVE-2026-102704 · Infrastructure
NO FIX YET
Xen caches validation data across batches of grant copy operations, and the check that restricts copying by frame number to a caller's own memory is misplaced. A guest may be able to copy memory belonging to other domains, which can expose data across virtual machine boundaries.
first public Nov 4, 2026 · 1 source
Is this in your stack? Find out in 2 minutes.
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
Affects Xen hypervisor hosts that run guest virtual machines using grant table copy operations. The sources do not state which Xen versions are affected or which configurations are exposed. Systems not running Xen can skip it.
Who cares hypervisor, self-hosted, virtualization, xen
Unknown from the sources.
No fix yet, per the sources.
[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]
A common access pattern is a batch of Grant Copy operations acting on adjacent address ranges in the same source or destination page. For performance reasons, Xen caches details internally to reuse already validated data. The conditions on when to re-validate the internal data were not correct in some cases:
Frame numbers and grant references could wrongly be mixed up. This is CVE-2026-102703.
Copying by frame number (rather than grant reference) is permitted only when operating on the caller's own memory. The check to enforce this restriction was misplaced. This is CVE-2026-102704.
This page as .md · .json · in your agent: get_signal("CVE-2026-102704")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.