When the code processing grant table transfer requests finds a page with an address too large to be represented in the interface with the guest, it allocates a replacement page and copies page contents. However, the code doing so fails to set the newly allocated page’s accounting properties correctly, resulting in the page becoming not only unusable by the target domain, but also unfreeable upon domain cleanup. The page as well as certain other remnants of an affected guest will be leaked.
Furthermore internal state of the processing code was also not updated correctly, resulting in the insertion of an IOMMU mapping to the page being replaced (and subsequently freed), allowing the domain access to memory it does not own.
The primary impact is a memory leak. Malicious or buggy guests with passed through PCI devices may also be able to escalate their privileges, crash the host, or access data belonging to other guests.
All Xen versions from at least 3.2 onwards are vulnerable.
64-bit x86 PV guests can leverage the vulnerability on hosts with physical memory extending past the 16 TiB boundary. This is only possible for hypervisors built with CONFIG_BIGMEM enabled.
32-bit x86 PV guests can leverage the vulnerability on hosts with physical memory extending past the 168 GiB boundary.
x86 HVM and PVH guests cannot leverage the vulnerability on libxl based systems. On xend based systems x86 HVM guests can leverage the vulnerability if their guest config file has a ‘machine_address_size’ setting.
ARM systems are not vulnerable.