Xen Security Advisory XSA-190 version 2 CR0.TS and CR0.EM not always honored for x86 HVM guests *** EMBARGOED UNTIL 2016-10-04 12:00 UTC *** UPDATES IN VERSION 2 ==================== Remove aside which suggests that the vulnerability is exposed only to multi-vcpu guests. Most HVM guests have access to DMA-capable devices (at least in the form of emulated ones), and are therefore indeed able to asynchronously overwrite the instructions being emulated even if they have only a single vcpu. ISSUE DESCRIPTION ================= Instructions touching FPU, MMX, or XMM registers are required to raise a Device Not Available Exception (#NM) when either CR0.EM or CR0.TS are set. (Their AVX or AVX-512 extensions would consider only CR0.TS.) While during normal operation this is ensured by the hardware, if a guest modifies instructions while the hypervisor is preparing to emulate them, the #NM delivery could be missed. Guest code in one task may thus (unintentionally or maliciously) read or modify register state belonging to another task in the same VM. IMPACT ====== A malicious unprivileged guest user may be able to obtain or corrupt sensitive information (including cryptographic material) in other programs in the same guest. VULNERABLE SYSTEMS ================== All versions of Xen expose the vulnerabilty to their x86 HVM guests. In order to exploit the vulnerability, the attacker needs to be able to trigger the Xen instruction emulator. On Xen 4.7 the emulator can only be triggered: by user mode tasks which have been given access to memory-mapped IO; in guests which have been migrated between systems with CPUs from different vendors; or in guests which have been configured with a CPU vendor different from the host's. On Xen 4.6 and earlier, all HVM guests can trigger the emulator by attempting to execute an invalid opcode, exposing the vulnerability. The vulnerability is only exposed to x86 HVM guests. The vulnerability is not exposed to x86 PV or ARM guests. MITIGATION ========== On Xen 4.7, not migrating across CPU vendors will avoid this vulnerability. (Unless the guest grants mmio access to unprivileged tasks, or has been configured with a specific CPU vendor, eg using the xl "cpuid" configuraton option.) RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa190.patch xen-unstable, Xen 4.7.x xsa190-4.6.patch Xen 4.6.x xsa190-4.5.patch Xen 4.5.x, Xen 4.4.x $ sha256sum xsa190* c198781b4fd60606cb5a4f21fa1ffbf13cbb6b047c54e3ca077de6de0bbfff3f xsa190.patch 6d203085f4ddb208427d927ef385744bc71ba0c319d3b3c6e277a684906393aa xsa190-4.5.patch 20d4cb617c0889fefa7dd948bec0f84ada9ca25165c27bcffbb094724a4b5045 xsa190-4.6.patch $
pushed/fixed in tree, thanks Arches, please test and mark stable: =app-emulation/xen-4.6.3-r3 Target keyword only: "amd64" =app-emulation/xen-tools-4.6.3-r2 Target keyword: "amd64 x86"
amd64 stable
x86 stable. Maintainer(s), please cleanup. Security, please vote.
old version has been dropped commit 8763e08ccb1ba9b8b533f49c57e4821b22d96050 Author: Yixun Lan <dlan@gentoo.org> Date: Fri Nov 4 18:15:09 2016 +0800 app-emulation/xen: drop old vulnerable version Gentoo-Bug: 594850 Package-Manager: portage-2.3.2 :100644 100644 0e44681... b9e1493... M app-emulation/xen/Manifest :100644 000000 5884d56... 00000000.. D app-emulation/xen/xen-4.6.3-r2.ebuild :100644 000000 5773cce... 00000000.. D app-emulation/xen/xen-4.7.0-r2.ebuild commit cc5bcd37b90e4260d696b0c328895128807f9621 Author: Yixun Lan <dlan@gentoo.org> Date: Fri Nov 4 18:13:42 2016 +0800 app-emulation/xen-tools: drop old vulnerable version Gentoo-Bug: 594850 Package-Manager: portage-2.3.2 :100644 100644 1b735b5... 38489f8... M app-emulation/xen-tools/Manifest :100644 000000 91f180a... 00000000.. D app-emulation/xen-tools/xen-tools-4.6.3-r1.ebuild :100644 000000 6630bd7... 00000000.. D app-emulation/xen-tools/xen-tools-4.7.0-r1.ebuild
This issue was resolved and addressed in GLSA 201611-09 at https://security.gentoo.org/glsa/201611-09 by GLSA coordinator Aaron Bauman (b-man).