-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2017-17566 / XSA-248 version 3 x86 PV guests may gain access to internally used pages UPDATES IN VERSION 3 ==================== CVE assigned. 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. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa248.patch xen-unstable, Xen 4.9.x xsa248-4.8.patch Xen 4.8.x, Xen 4.7.x, Xen 4.6.x xsa248-4.5.patch Xen 4.5.x $ sha256sum xsa248* f0ac5c5ff956118f52821e111c6e27416f788cea6e98cc54cb051c42b793357e xsa248.meta 20bcfb1890d90bd74f52e45a1e8aa020a8991e3a0db37eecf53ce48b16e602bf xsa248.patch ec4227633df18f76fbd8cb12e367879470b63fb5236f10b2a971dccef9f83172 xsa248-4.5.patch 3bbd9fd92e5ffab1ddd7ff804bfbab09c1c654af3aa7f80f742f321da120b715 xsa248-4.8.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJaUPXWAAoJEIP+FMlX6CvZ5R8H/Rn0CZ9fEExfAjcqm5kjTZFt HgI+ZfUYwhEfMuYc4bv5rYYfzhFsCWe4afrcxBdh1qtMeJjZWfGtf8yOFNzox0PR XeMZ/p7qwspg9TyNO/7dM+wd6nHRp88pTcy4QQcmfczcZrcUbm0wGCmhaIJdWlMA CsgKsiekPapB9R+fqeVroc/gmMRx9iTFif/w96OpApGsMPO5SnuSzeFrL8RzMU9u rjwCfu0Yz9MPHT8E+KvI9GeB7srov3XEfMsmaJ9NUDgnrDl9Xhe5wC7FnL3mvTYC YZML85QbvghxFoQM6v2MyBwF8tLW3YEgZK/oR4ed1E6BrKfDQwyXIaT0GXtIFzk= =ytqY -----END PGP SIGNATURE-----