-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2017-15594 / XSA-244 version 3 x86: Incorrect handling of IST settings during CPU hotplug UPDATES IN VERSION 3 ==================== CVE assigned. ISSUE DESCRIPTION ================= The x86-64 architecture allows interrupts to be run on distinct stacks. The choice of stack is encoded in a field of the corresponding interrupt descriptor in the Interrupt Descriptor Table (IDT). That field selects an entry from the active Task State Segment (TSS). Since, on AMD hardware, Xen switches to an HVM guest's TSS before actually entering the guest, with the Global Interrupt Flag still set, the selectors in the IDT entry are switched when guest context is loaded/unloaded. When a new CPU is brought online, its IDT is copied from CPU0's IDT, including those selector fields. If CPU0 happens at that moment to be in HVM context, wrong values for those IDT fields would be installed for the new CPU. If the first guest vCPU to be run on that CPU belongs to a PV guest, it will then have the ability to escalate its privilege or crash the hypervisor. IMPACT ====== A malicious or buggy x86 PV guest could escalate its privileges or crash the hypervisor. VULNERABLE SYSTEMS ================== All Xen versions from at least 3.2 onwards are vulnerable. Earlier versions have not been checked. Only PV guests can exploit the vulnerability. HVM guests cannot exploit the vulnerability, but their presence is necessary for the exposure of the vulnerability to PV guests. Only x86 systems using SVM (AMD virtualisation extensions) rather than VMX (Intel virtualisation extensions) are vulnerable. Therefore AMD x86 hardware is vulnerable; Intel hardware is not vulnerable. ARM systems are not vulnerable. MITIGATION ========== Avoiding to online CPUs at runtime will avoid this vulnerability. Running only HVM or only PV guests on any individual host will also avoid this vulnerability. CREDITS ======= This issue was discovered by Andrew Cooper of Citrix. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa244.patch xen-unstable, Xen 4.9.x, Xen 4.8.x xsa244-4.7.patch Xen 4.7.x xsa244-4.6.patch Xen 4.6.x xsa244-4.5.patch Xen 4.5.x $ sha256sum xsa244* 5b663620a1b0d5f07e7ae4d1d3506d925515d5f85830ca49dda75cab1218506f xsa244.meta bcf22b332bf3f6fe8c86e4de67f82628c9b8e257d9513c3bf5c7f5dd71d86c33 xsa244.patch 4c4543fdfd25b4a8ea7d53f3f45011ec137798e7d4e690d8f3ea58d77afb5f06 xsa244-4.5.patch eaa3ba303980d783813db7aee948a9cb2723328da5fa5650ffca7b825c21bab6 xsa244-4.6.patch 4d8cf754f760ef05488e9fb25a7ebd9a7e46f3742e91eee1a8385fd1e611ea8c xsa244-4.7.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 iQEcBAEBCAAGBQJZ50QqAAoJEIP+FMlX6CvZmsEIAKuPA1/ly1Hgf9vZCkbKauO/ df8JgVdLemcGSEfDwzVlRjHQh0QtpMLNG5RCYRD+s8hrCotKc8dC95+pIztDY/l+ lw6k9bCFup7hI++IdL/fmy79RS+WUOinMEOwD39zqFVK+y6J2M0iXnuKqxtF+j/7 zWVmzdZIHbM+6DlRr1uN0jpirqkJ8P5yNMBgqhp4zH4efOe0Olv+0SQtNtNclCib MR4ipBbkK9sCMN6odZCbnwKkn2zyCDSfPiXnINfiIbsUweCf9n6MEpry8Kiae90Z BFn+KGkRcC9gQkoKRoF/rDwG02P6KCb34pNY0nVgxtr4pDYqJzhEh7+eGXfVHME= =dk0t -----END PGP SIGNATURE-----