From http://www.openwall.com/lists/oss-security/2015/03/31/5: Xen Security Advisory CVE-2015-2752 / XSA-125 version 3 Long latency MMIO mapping operations are not preemptible UPDATES IN VERSION 3 ==================== CVE assigned. Public release. ISSUE DESCRIPTION ================= The XEN_DOMCTL_memory_mapping hypercall allows long running operations without implementing preemption. This hypercall is used by the device model as part of the emulation associated with configuration of PCI devices passed through to HVM guests and is therefore indirectly exposed to those guests. This can cause a physical CPU to become busy for a significant period, leading to a host denial of service in some cases. If a host denial of service is not triggered then it may instead be possible to deny service to the domain running the device model, e.g. domain 0. This hypercall is also exposed more generally to all toolstacks. However the uses of it in libxl based toolstacks are not believed to open up any avenue of attack from an untrusted guest. Other toolstacks may be vulnerable however. IMPACT ====== The vulnerability is exposed via HVM guests which have a PCI device assigned to them. A malicious HVM guest in such a configuration can mount a denial of service attack affecting the whole system via its associated device model (qemu-dm). A guest is able to trigger this hypercall via operations which it is legitimately expected to perform, therefore running the device model as a stub domain does not offer protection against the host denial of service issue. However it does offer some protection against secondary issues such as denial of service against dom0. VULNERABLE SYSTEMS ================== The issue is exposed via x86 HVM VMs which have been assigned a PCI device. x86 PV domains, x86 HVM domains without passthrough devices and ARM domains do not expose this vulnerability. Xen 3.2.x and later are vulnerable. Xen 3.1.x and earlier have not been inspected. MITIGATION ========== Running only PV guests will avoid this issue. This issue can be avoided by not assigning devices with large MMIO regions to untrusted HVM guests. CREDITS ======= This issue was discovered by Konrad Rzeszutek Wilk of Oracle. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa125.patch Xen 4.5.x, xen-unstable xsa125-4.4.patch Xen 4.4.x xsa125-4.3.patch Xen 4.3.x xsa125-4.2.patch Xen 4.2.x From http://www.openwall.com/lists/oss-security/2015/03/31/7: Xen Security Advisory CVE-2015-2756 / XSA-126 version 3 Unmediated PCI command register access in qemu UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= HVM guests are currently permitted to modify the memory and I/O decode bits in the PCI command register of devices passed through to them. Unless the device is an SR-IOV virtual function, after disabling one or both of these bits subsequent accesses to the MMIO or I/O port ranges would - on PCI Express devices - lead to Unsupported Request responses. The treatment of such errors is platform specific. Furthermore (at least) devices under control of the Linux pciback driver in the host are handed to guests with the aforementioned bits turned off. This means that such accesses can similarly lead to Unsupported Request responses until these flags are set as needed by the guest. IMPACT ====== In the event that the platform surfaces aforementioned UR responses as Non-Maskable Interrupts, and either the OS is configured to treat NMIs as fatal or (e.g. via ACPI's APEI) the platform tells the OS to treat these errors as fatal, the host would crash, leading to a Denial of Service. VULNERABLE SYSTEMS ================== Xen versions 3.3 and onwards are vulnerable due to supporting PCI pass-through. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only HVM guests with their device model run in Dom0 can take advantage of this vulnerability. Any domain which is given access to a non-SR-IOV virtual function PCI Express device can take advantage of this vulnerability. MITIGATION ========== This issue can be avoided by not assigning PCI Express devices other than SR-IOV virtual functions to untrusted HVM guests. This issue can also be avoided by only using PV guests or HVM guests with their device model run in a separate (stub) domain. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa126-qemuu.patch qemu-upstream-unstable, Xen 4.5.x, Xen 4.4.x xsa126-qemuu-4.3.patch qemu-upstream-unstable, Xen 4.3.x xsa126-qemut.patch qemu-xen-unstable, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x For those already having the original patch in place, applying the appropriate attached incremental patch addresses the regression. xsa126-qemuu-incr.patch qemu-upstream-unstable, Xen 4.5.x, Xen 4.4.x xsa126-qemuu-4.3-incr.patch qemu-upstream-unstable, Xen 4.3.x xsa126-qemut-incr.patch qemu-xen-unstable, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x From http://www.openwall.com/lists/oss-security/2015/03/31/6: Xen Security Advisory CVE-2015-2751 / XSA-127 version 2 Certain domctl operations may be abused to lock up the host UPDATES IN VERSION 2 ==================== CVE assigned. Public release. ISSUE DESCRIPTION ================= XSA-77 put the majority of the domctl operations on a list excepting them from having security advisories issued for them if any effects their use might have could hamper security. Subsequently some of them got declared disaggregation safe, but for a small subset this was not really correct: Their (mis-)use may result in host lockups. As a result, the potential security benefits of toolstack disaggregation are not always fully realised. IMPACT ====== Domains deliberately given partial management control may be able to deny service to the entire host. As a result, in a system designed to enhance security by radically disaggregating the management, the security may be reduced. But, the security will be no worse than a non-disaggregated design. VULNERABLE SYSTEMS ================== Xen versions 4.3 onwards are vulnerable. Xen versions 4.2 and earlier do not have the described disaggregation functionality and hence are not vulnerable. MITIGATION ========== The issues discussed in this advisory are themselves bugs in features used for a security risk mitigation. There is no further mitigation available, beyond general measures to try to avoid parts of the system management becoming controlled by attackers. Those are the kind of measures which we expect any users of radical disaggregation to have already deployed. Switching from disaggregated to a non-disaggregated operation does NOT mitigate these vulnerabilities. Rather, it simply recategorises the vulnerability to hostile management code, regarding it "as designed"; thus it merely reclassifies these issues as "not a bug". Users and vendors of disaggregated systems should not change their configuration. The robustness benefits of disaggregation are unaffected, and (depending on system design) security benefits are likely to remain despite the vulnerabilities. CREDITS ======= This issue was discovered by Andrew Cooper of Citrix. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa127-unstable.patch xen-unstable xsa127-4.x.patch Xen 4.5.x, Xen 4.4.x, Xen 4.3.x @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
*** Bug 543654 has been marked as a duplicate of this bug. ***
fixed in following versions: app-emulation/xen-4.5.0-r5 app-emulation/xen-4.4.2-r1 app-emulation/xen-4.2.5-r8 app-emulation/xen-tools-4.5.0-r3 app-emulation/xen-tools-4.4.2-r1 app-emulation/xen-tools-4.2.5-r4 Arches, please test and mark stable: =app-emulation/xen-4.2.5-r8 =app-emulation/xen-tools-4.2.5-r4 Target keywords Both : "amd64 x86" =app-emulation/xen-4.4.2-r1 =app-emulation/xen-tools-4.4.2-r1 =app-emulation/xen-pvgrub-4.4.2 Target keywords Only: "amd64"
why on earth did you duplicate this bug already made days 'ago' with comments re its progress? I support dlan's decision to bump with the patches we have that DO take and work. version 4.3 has a troublesome 1, xsa126-qemuu-4.3.patch that is the source of the holdup in that version
amd64 stable
x86 stable. Maintainer(s), please cleanup. Security, please vote.
Cancel ref to version 4.3 which had been dropped. 03 Apr 2015; Yixun Lan <dlan@gentoo.org> -xen-4.2.5-r6.ebuild, -xen-4.2.5-r7.ebuild, -xen-4.4.2.ebuild, -xen-4.5.0-r4.ebuild: drop old after new stabilization 03 Apr 2015; Yixun Lan <dlan@gentoo.org> -xen-tools-4.2.5-r3.ebuild, -xen-tools-4.4.2.ebuild, -xen-tools-4.5.0-r2.ebuild: drop old after new stabilization
CVE-2015-2756 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-2756): QEMU, as used in Xen 3.3.x through 4.5.x, does not properly restrict access to PCI command registers, which might allow local HVM guest users to cause a denial of service (non-maskable interrupt and host crash) by disabling the (1) memory or (2) I/O decoding for a PCI Express device and then accessing the device, which triggers an Unsupported Request (UR) response. CVE-2015-2752 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-2752): The XEN_DOMCTL_memory_mapping hypercall in Xen 3.2.x through 4.5.x, when using a PCI passthrough device, is not preemptable, which allows local x86 HVM domain users to cause a denial of service (host CPU consumption) via a crafted request to the device model (qemu-dm). CVE-2015-2751 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-2751): Xen 4.3.x, 4.4.x, and 4.5.x, when using toolstack disaggregation, allows remote domains with partial management control to cause a denial of service (host lock) via unspecified domctl operations.
Arches and Maintainer(s), Thank you for your work. Added to an existing GLSA Request.
This issue was resolved and addressed in GLSA 201504-04 at https://security.gentoo.org/glsa/201504-04 by GLSA coordinator Yury German (BlueKnight).
