ISSUE DESCRIPTION ================= Memory management for PV guests builds on page ownership and page attributes. A domain can always map, at least r/o, pages of which it is the owner. Certain fields in the control structure of a page are used for different purposes in the main PV memory management code and in code handling shadow paging. When a guest is running in shadow mode (which for PV guests is necessary e.g. for live migration), certain auxiliary pages used by Xen internally had their owner set to the guest itself. When the PV guest maps such a page, shadow code and PV memory management code will disagree on the meaning of said multi-purpose fields, generally leading to a crash of the hypervisor. IMPACT ====== A malicious or buggy PV 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 versions of Xen are vulnerable. Only x86 systems are affected. ARM systems are not vulnerable. x86 HVM guests cannot exploit this vulnerability. Only x86 PV guests can exploit this vulnerability, and only when being run in shadow mode. PV guests are typically run in shadow mode for 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). MITIGATION ========== Running only HVM guests avoids the vulnerability. Avoiding live migration of x86 PV guests also avoids the vulnerability. External References: http://xenbits.xen.org/xsa/advisory-248.html
Acknowledgments: Name: the Xen project Upstream: Jan Beulich (SUSE)
Created xen tracking bugs for this issue: Affects: fedora-all [bug 1525018]