ISSUE DESCRIPTION ================= Pages being used to run x86 guests in shadow mode are reference counted to track their uses. When another reference cannot be acquired, the corresponding page table entry must not be inserted. Due to incorrect error handling, this constraint could be violated. IMPACT ====== A malicious or buggy guest may cause a hypervisor crash, resulting in a Denial of Service (DoS) affecting the entire host, or cause hypervisor memory corruption. We cannot rule out a guest being able to escalate its privilege. VULNERABLE SYSTEMS ================== All Xen versions are affected. x86 systems are vulnerable. ARM systems are not vulnerable. Only guests run in shadow mode can exploit the vulnerability. PV guests typically only run in shadow mode during live migration, as well as for features like VM snapshot. Note that save / restore does *not* use shadow mode, and so does not expose this vulnerability. Some downstreams also include a "non-live migration" feature, which also does not use shadow mode (and thus does not expose this vulnerability). HVM guests run in shadow mode on hardware without HAP support, or when HAP is disabled (globally or in the VM configuration file). Live migration does not affect an HVM guest's use of shadow mode. MITIGATION ========== For HVM guest explicitly configured to use shadow paging (e.g. via the `hap=0' xl domain configuration file parameter), changing to HAP (e.g. by setting `hap=1') will avoid exposing the vulnerability to those guests. HAP is the default (in upstream Xen), where the hardware supports it; so this mitigation is only applicable if HAP has been disabled by configuration. For PV guests, avoiding their live migration avoids the vulnerability. External References: http://xenbits.xen.org/xsa/advisory-250.html
Acknowledgments: Name: the Xen project Upstream: Jan Beulich (SUSE)
Created xen tracking bugs for this issue: Affects: fedora-all [bug 1525018]