Date: Wed, 07 Dec 2016 10:32:41 +0000 From: Xen.org security team <security@....org> To: xen-announce@...ts.xen.org, xen-devel@...ts.xen.org, xen-users@...ts.xen.org, oss-security@...ts.openwall.com CC: Xen.org security team <security@....org> Subject: Xen Security Advisory 201 (CVE-2016-9815,CVE-2016-9816,CVE-2016-9817,CVE-2016-9818) - ARM guests may induce host asynchronous abort -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2016-9815,CVE-2016-9816,CVE-2016-9817,CVE-2016-9818 / XSA-201 version 2 ARM guests may induce host asynchronous abort UPDATES IN VERSION 2 ==================== CVEs assigned. ISSUE DESCRIPTION ================= Depending on how the hardware and firmware have been integrated, guest-triggered asynchronous aborts (SError on ARMv8) may be received by the hypervisor. The current action is to crash the host. A guest might trigger an asynchronous abort when accessing memory mapped hardware in a non-conventional way. Even if device pass-through has not been configured, the hypervisor may give the guest access to memory mapped hardware in order to take advantage of hardware virtualization. The CVEs are as follows: xsa201-1.patch CVE-2016-9815 xsa201-2.patch CVE-2016-9816 xsa201-3-*.patch CVE-2016-9817 xsa201-4.patch CVE-2016-9818 IMPACT ====== A malicious guest may be able to crash the host. VULNERABLE SYSTEMS ================== All Xen versions which support ARM are potentially affected. Whether a particular ARM systems is affected depends on technical details of the hardware and/or firmware. x86 systems are not affected. MITIGATION ========== On systems where the guest kernel is controlled by the host rather than guest administrator, running only kernels which do not expose MMIO to userspace will prevent untrusted guest users from exploiting this issue. However untrusted guest administrators can still trigger it unless further steps are taken to prevent them from loading code into the kernel (e.g by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. NOTE REGARDING LACK OF EMBARGO ============================== The issue was discussed publicly (and has been fixed already in KVM in public trees). CREDITS ======= This issue was discovered by ARM engineering personnel. RESOLUTION ========== Applying the appropriate set of attached patched resolves this issue. xsa201-.patch Xen-unstable xsa201-.patch } xsa201-3-4.7.patch } Xen 4.7.x, Xen 4.6.x xsa201-4.patch } $ sha256sum xsa201* 163aeb9ae3ffce28e0bc95bdfff490d2df6f6f0b85ac1d4f447bea921f0a0dda xsa201-1.patch 0ba570ed7df172475bc745e02b89670608251634895e5279edcf534619d6d81b xsa201-2.patch 4045e046473f069c51e5fd579f63563862aa497d945b183c768481ef11885744 xsa201-3.patch a9cf56564d020675c0f2f1ea15009a712f172be3d53ea8ddf2f48adaac392e76 xsa201-3-4.7.patch 388d548cd4e30883ae100863d33e792869e7dbd86054299a91b64db6d6599919 xsa201-4.patch $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYR+VFAAoJEIP+FMlX6CvZVZkIAKygymoB/4TYWHSQCDaekqe7 oqs0SrOZwAiaXDDtNEq5oUmWzw852p6ewHzeHkuFrpXSTg9NZqE3ve/Ygy4z2lwQ jlrQblTl1wopoJDKFfvVqnGX4sEQvDqsOKAYpX0LbtjiIOAisKNT5f40J9X3L2Oz dzEdMuKDNvCDO6hPbDXprDDP9qETO4+Wopsj14F6rraYICrMl1P1LKabwr12936s XuegVU25S777YJ3CXpJVSCGns6zZzJm345l1VdgQ5M+KmMQkb4P+v5do7rMHMZFU LvYqxT9M+V6EDylByNp1HuYJWFQU7jgH/oK4k0M3EHAuovN5GZKp7SdGywVEEwY= =t4pk -----END PGP SIGNATURE----- Download attachment "xsa201-1.patch" of type "application/octet-stream" (3093 bytes) Download attachment "xsa201-2.patch" of type "application/octet-stream" (6468 bytes) Download attachment "xsa201-3.patch" of type "application/octet-stream" (1673 bytes) Download attachment "xsa201-3-4.7.patch" of type "application/octet-stream" (1650 bytes) Download attachment "xsa201-4.patch" of type "application/octet-stream" (4484 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ