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