Xen Security Advisory XSA-155 version 3 paravirtualized drivers incautious about shared memory contents *** EMBARGOED UNTIL 2015-12-17 12:00 UTC *** UPDATES IN VERSION 3 ==================== Update Xen patches against Xen 4.4 and fix compile issue with patch against Xen 4.5. Furthermore provide backport patches against Linux v4.3, v4.2, v4.1, v4.0 and v3.19. The GCC non-propagation of volatile bug has been determined to not affect the PV drivers covered by these patches. Therefore the original patches are effective against this issue. ISSUE DESCRIPTION ================= The compiler can emit optimizations in the PV backend drivers which can lead to double fetch vulnerabilities. Specifically the shared memory between the frontend and backend can be fetched twice (during which time the frontend can alter the contents) possibly leading to arbitrary code execution in backend. IMPACT ====== Malicious guest administrators can cause denial of service. If driver domains are not in use, the impact can be a host crash, or privilege escalation. VULNERABLE SYSTEMS ================== Systems running PV or HVM guests are vulnerable. ARM and x86 systems are vulnerable. All OSes providing PV backends are susceptible, this includes Linux and NetBSD. By default the Linux distributions compile kernels with optimizations. MITIGATION ========== There is no mitigation. RESOLUTION ========== Applying the appropriate attached patches should fix the problem for PV backends. Note only that PV backends are fixed; PV frontend patches will be developed and released (publicly) after the embargo date. Please note that there is a bug in some versions of gcc, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 which can cause the construct used in RING_COPY_REQUEST() to be ineffective in some circumstances. We have determined that this is only the case when the structure being copied consists purely of bitfields. The Xen PV protocols updated here do not use bitfields in this way and therefore these patches are not subject to that bug. However authors of third party PV protocols should take this into consideration. Linux v4.4: xsa155-linux-xsa155-0001-xen-Add-RING_COPY_REQUEST.patch xsa155-linux-xsa155-0002-xen-netback-don-t-use-last-request-to-determine-mini.patch xsa155-linux-xsa155-0003-xen-netback-use-RING_COPY_REQUEST-throughout.patch xsa155-linux-xsa155-0004-xen-blkback-only-read-request-operation-from-shared-.patch xsa155-linux-xsa155-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch xsa155-linux-xsa155-0006-xen-scsiback-safely-copy-requests.patch xsa155-linux-xsa155-0007-xen-pciback-Save-xen_pci_op-commands-before-processi.patch Linux v4.[0,1,2,3] All the above patches except #5 will apply, please use: xsa155-linux43-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch Linux v3.19: All the above patches except #5 and #6 will apply, please use: xsa155-linux43-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch xsa155-linux319-0006-xen-scsiback-safely-copy-requests.patch qemu-xen: xsa155-qemu-qdisk-double-access.patch xsa155-qemu-xenfb.patch qemu-traditional: xsa155-qemut-qdisk-double-access.patch xsa155-qemut-xenfb.patch NetBSD 7.0: xsa155-netbsd-xsa155-0001-netbsd-xen-Add-RING_COPY_REQUEST.patch xsa155-netbsd-xsa155-0002-netbsd-netback-Use-RING_COPY_REQUEST-instead-of-RING.patch xsa155-netbsd-xsa155-0003-netbsd-ring-Add-barrier-to-provide-an-compiler-barri.patch xsa155-netbsd-xsa155-0004-netbsd-block-only-read-request-operation-from-shared.patch xsa155-netbsd-xsa155-0005-netbsd-pciback-Operate-on-local-version-of-xen_pci_o.patch xen: xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch xen 4.4: All patches except #3 will apply, please use: xsa155-xen44-0003-libvchan-Read-prod-cons-only-once.patch $ sha256sum xsa155* d9fbc104ab2ae797971e351ee0e04e7b7e9c7c33385309bb406c7941dc9a33b4 xsa155-linux319-xsa155-0006-xen-scsiback-safely-copy-requests.patch 590656d83ad7b6052b54659eccb3469658b3942c0dc1366423a66f2f5ac643e1 xsa155-linux43-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch 2bd18632178e09394c5cd06aded2c14bcc6b6e360ad6e81827d24860fe3e8ca4 xsa155-linux-xsa155-0001-xen-Add-RING_COPY_REQUEST.patch cecdeccb8e2551252c81fc5f164a8298005df714a574a7ba18b84e8ed5f2bb70 xsa155-linux-xsa155-0002-xen-netback-don-t-use-last-request-to-determine-mini.patch 3916b847243047f0e1053233ade742c14a7f29243584e60bf5db4842a8068855 xsa155-linux-xsa155-0003-xen-netback-use-RING_COPY_REQUEST-throughout.patch 746c8eb0aeb200d76156c88dfbbd49db79f567b88b07eda70f7c7d095721f05a xsa155-linux-xsa155-0004-xen-blkback-only-read-request-operation-from-shared-.patch 18517a184a02f7441065b8d3423086320ec4c2345c00d551231f7976381767f5 xsa155-linux-xsa155-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch 2e6d556d25b1cc16e71afde665ae3908f4fa8eab7e0d96283fc78400301baf92 xsa155-linux-xsa155-0006-xen-scsiback-safely-copy-requests.patch 5e130d8b61906015c6a94f8edd3cce97b172f96a265d97ecf370e7b45125b73d xsa155-linux-xsa155-0007-xen-pciback-Save-xen_pci_op-commands-before-processi.patch 08c2d0f95dcc215165afbce623b6972b81dd45b091b5f40017579b00c8612e03 xsa155-netbsd-xsa155-0001-netbsd-xen-Add-RING_COPY_REQUEST.patch 0a66010f736092f91f70bb0fd220685e4395efef1db6d23a3d1eace31d144f51 xsa155-netbsd-xsa155-0002-netbsd-netback-Use-RING_COPY_REQUEST-instead-of-RING.patch 5e913a8427cab6b4d384d1246e05116afc301eb117edd838101eb53a82c2f2ff xsa155-netbsd-xsa155-0003-netbsd-ring-Add-barrier-to-provide-an-compiler-barri.patch 3b8f14eafaed3a7bc66245753a37af4249acf8129fbedb70653192252dc47dc9 xsa155-netbsd-xsa155-0004-netbsd-block-only-read-request-operation-from-shared.patch 81ae5fa998243a78dad749fc561be647dc1dc1be799e8f18484fdf0989469705 xsa155-netbsd-xsa155-0005-netbsd-pciback-Operate-on-local-version-of-xen_pci_o.patch 044ff74fa048df820d528f64f2791ec9cb3940bd313c1179020bd49a6cde2ca3 xsa155-qemu-qdisk-double-access.patch 1150504589eb7bfa108c80ce63395e57d0e627b12d9201219d968fdd026919a6 xsa155-qemut-qdisk-double-access.patch 63186246ab6913b54bfef5f09f33e815935ac40ff821c27a3efda62339bbbd5f xsa155-qemut-xenfb.patch e53b4ac298648cde79344192d5a58ca8d8724344f5105bec7c09eef095c668f6 xsa155-qemu-xenfb.patch e52467fcec73bcc86d3e96d06f8ca8085ae56a83d2c42a30c16bc3dc630d8f8a xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch eae34c8ccc096ad93a74190506b3d55020a88afb0cc504a3a514590e9fd746fd xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch 42780265014085a4221ad32b026214693d751789eb5219e2e83862c0006c66f4 xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch dfcaddb8a908a4fc1b048a43187e885117e67dc566f5c841037ee366dcd437d1 xsa155-xen44-0003-libvchan-Read-prod-cons-only-once.patch $ ______________________________ Xen Security Advisory XSA-157 Linux pciback missing sanity checks leading to crash *** EMBARGOED UNTIL 2015-12-17 12:00 UTC *** ISSUE DESCRIPTION ================= Xen PCI backend driver does not perform proper sanity checks on the device's state. Which in turn allows the generic MSI code (called by Xen PCI backend) to be called incorrectly leading to hitting BUG conditions or causing NULL pointer exceptions in the MSI code. To exploit this the guest can craft specific sequence of XEN_PCI_OP_* operations which will trigger this. Furthermore the frontend can also craft an continous stream of XEN_PCI_OP_enable_msi which will trigger an continous stream of WARN() messages triggered by the MSI code leading to the logging in the initial domain to exhaust disk space. Lastly there is also missing check to verify whether the device has memory decoding enabled set at the start of the day leading the initial domain "accesses to the respective MMIO or I/O port ranges would - - on PCI Express devices - [which can] lead to Unsupported Request responses. The treatment of such errors is platform specific." (from XSA-120). Note that if XSA-120 'addendum' patch has been applied this particular sub-issue is not exploitable. IMPACT ====== Malicious guest administrators can cause denial of service. If driver domains are not in use, the impact is a host crash. Only x86 systems are vulnerable. ARM systems are not vulnerable. VULNERABLE SYSTEMS ================== This bug affects systems using Linux as the driver domain, including non-disaggregated systems using Linux as dom0. Linux versions v3.1 and onwards are vulnerable due to supporting PCI pass-through backend driver. PV and HVM guests which have been granted access to physical PCI devices (`PCI passthrough') can take advantage of this vulnerability. Furthermore, the vulnerability is only applicable when the passed-through PCI devices are MSI-capable or MSI-X. (Most modern devices are). MITIGATION ========== Not using PCI passthrough for PV and HVM guests. Note that for HVM guests QEMU is used for PCI passthrough - however the toolstack sets up also the 'PV' PCI which the guest can utilize if it chooses to do so. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. Linux 4.3: xsa157-0001-xen-pciback-Return-error-on-XEN_PCI_OP_enable_msi-wh.patch xsa157-0002-xen-pciback-Return-error-on-XEN_PCI_OP_enable_msix-w.patch xsa157-0003-xen-pciback-Do-not-install-an-IRQ-handler-for-MSI-in.patch xsa157-0004-xen-pciback-For-XEN_PCI_OP_disable_msi-x-only-disabl.patch xsa157-0005-xen-pciback-Don-t-allow-MSI-X-ops-if-PCI_COMMAND_MEM.patch $ sha256sum xsa157* 0cb2d1729f17e640e33f11945f2e12eba85071238fab2dcc42f81b5d942c159b xsa157-0001-xen-pciback-Return-error-on-XEN_PCI_OP_enable_msi-wh.patch 9bcb240a49a5cd48428cc9c01ee480297999b93f6977fdddd79ec715648aa244 xsa157-0002-xen-pciback-Return-error-on-XEN_PCI_OP_enable_msix-w.patch 7c39b33d0e2d751970bbe56f463661c50aa5e4addc8eee35b80e9e1378e97b02 xsa157-0003-xen-pciback-Do-not-install-an-IRQ-handler-for-MSI-in.patch 1acfd6f4ea13db6a146d547640f50d0ad40480b914b021760a518ac82e8e4c71 xsa157-0004-xen-pciback-For-XEN_PCI_OP_disable_msi-x-only-disabl.patch b864620709e4b55a908dd6955a090ca03a9a07cfb31b66e2e5211ab8f0c77e68 xsa157-0005-xen-pciback-Don-t-allow-MSI-X-ops-if-PCI_COMMAND_MEM.patch $ ______________________________ Xen Security Advisory XSA-164 qemu-dm buffer overrun in MSI-X handling *** EMBARGOED UNTIL 2015-12-17 12:00 UTC *** ISSUE DESCRIPTION ================= "qemu-xen-traditional" (aka qemu-dm) tracks state for each MSI-X table entry of a passed through device. This is used/updated on (intercepted) accesses to the page(s) containing the MSI-X table. There may be space on the final page not covered by any MSI-X table entry, but memory for state tracking is allocated only for existing table entries. Therefore bounds checks are required to avoid accessing/corrupting unrelated heap memory. Such a check is present for the read path, but was missing for the write path. IMPACT ====== A malicious administrator of a guest which has access to a passed through PCI device which is MSI-X capable can exploit this vulnerability to take over the qemu process, elevating its privilege to that of the qemu process. In a system not using a device model stub domain (or other techniques for deprivileging qemu), the malicious guest administrator can thus elevate their privilege to that of the host. VULNERABLE SYSTEMS ================== Xen systems running x86 HVM guests with "qemu-xen-traditional", but without stubdomains, which have been passed through an MSI-X capable physical PCI device are vulnerable. The default configuration is NOT vulnerable from Xen 4.3 onwards (because it uses a newer upstream qemu version). Systems running only PV guests are NOT vulnerable. Only systems using PCI passthrough are vulnerable. Systems using "qemu-xen-traditional" stubdomain device models (for example, by specifying "device_model_stubdomain_override=1" in xl's domain configuration files) are NOT vulnerable. Only the traditional "qemu-xen-traditional" device model is vulnerable. Upstream qemu device models ("qemu-xen") are NOT vulnerable. ARM systems are NOT vulnerable. MITIGATION ========== Not passing through MSI-X capable devices to HVM guests will avoid this vulnerability. Running HVM guests with the default upstream device model will also avoid this vulnerability. Enabling stubdomains will mitigate this issue, by reducing the escalation to only those privileges accorded to the service domain. In a usual configuration, a service domain has only the privilege of the guest, so this eliminates the vulnerability. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa164.patch qemu-xen-traditional: Xen unstable, 4.6.x, 4.5.x, 4.4.x, 4.3.x $ sha256sum xsa164* 40f7327aa414c77a0e18a305a144e4a720ba8fe1b618d2f3ad9d5f605667c340 xsa164.patch $
______________________________ Xen Security Advisory XSA-165 information leak in legacy x86 FPU/XMM initialization *** EMBARGOED UNTIL 2015-12-17 12:00 UTC *** ISSUE DESCRIPTION ================= When XSAVE/XRSTOR are not in use by Xen to manage guest extended register state, the initial values in the FPU stack and XMM registers seen by the guest upon first use are those left there by the previous user of those registers. IMPACT ====== A malicious domain may be able to leverage this to obtain sensitive information such as cryptographic keys from another domain. VULNERABLE SYSTEMS ================== All Xen versions are vulnerable. Only x86 systems without XSAVE support or with XSAVE support disabled are vulnerable. ARM systems are not vulnerable. MITIGATION ========== On XSAVE capable systems, not turning off XSAVE support via the "no-xsave" hypervisor command line option (or - when defaulting to off - turning it on via the "xsave" hypervisor command line option) will avoid the vulnerability. To find out whether XSAVE is in use, consult the hypervisor log (obtainable e.g. via "xl dmesg") and look for a message of the form "xstate_init: using cntxt_size: <number> and states: <number>" If such a message is present then XSAVE is in use. But note that due to log buffer size restrictions this boot time message may have scrolled off. There is no known mitigation on XSAVE-incapable systems. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa165.patch xen-unstable xsa165-4.6.patch Xen 4.6.x xsa165-4.5.patch Xen 4.5.x, Xen 4.4.x xsa165-4.3.patch Xen 4.3.x $ sha256sum xsa165* 6422db857dd469f5978b80be95e93d1db4bab965668430e07005b7b6369742be xsa165.patch bced245fb1111b7fa2db642971cceb0523e691367ba8bfbc6ff0da421f198c97 xsa165-4.3.patch dd15e301f2757e0c7975bdccfe49ddf41c730bc124dd90166e0844d332eeedad xsa165-4.5.patch 4bb18f2e44f49f140932c2d1e956e2e28017439cbb0e76eb16a8af617c4112ac xsa165-4.6.patch $ ______________________________ Xen Security Advisory XSA-166 ioreq handling possibly susceptible to multiple read issue *** EMBARGOED UNTIL 2015-12-17 12:00 UTC *** ISSUE DESCRIPTION ================= Single memory accesses in source code can be translated to multiple ones in machine code by the compiler, requiring special caution when accessing shared memory. Such precaution was missing from the hypervisor code inspecting the state of I/O requests sent to the device model for assistance. Due to the offending field being a bitfield, it is however believed that there is no issue in practice, since compilers, at least when optimizing (which is always the case for non-debug builds), should find it more expensive to extract the bit field value twice than to keep the calculated value in a register. IMPACT ====== This vulnerability is exposed to malicious device models. In conventional Xen systems this means the qemu which service an HVM domain. On such systems this vulnerability can only be exploited if the attacker has gained control of the device model qemu via another vulnerability. Privilege escalation, host crash (Denial of Service), and leaked information all cannot be excluded. VULNERABLE SYSTEMS ================== All Xen versions are affected. Only x86 variants of Xen are susceptible. ARM variants are not affected. Only HVM guests expose this vulnerability. MITIGATION ========== Running only PV guests will avoid this issue. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa166.patch xen-unstable, Xen 4.6.x xsa166-4.5.patch Xen 4.5.x xsa166-4.4.patch Xen 4.4.x xsa166-4.3.patch Xen 4.3.x $ sha256sum xsa166* 740a28a69524e966ab77f9f5e45067aa7ba2d32ea69b1d3c4b9bf0c86212ad0a xsa166.patch 109a9eb132d712a56a7ca81214fff3952868a39206eb34f66f5b2265e680b9fc xsa166-4.3.patch d63261ca2d40e2723a4f3c94665cc120e0ea488200eebb08c7aa07e1c1a35d42 xsa166-4.4.patch d5dddce37c644d35ef52ff7230f83bf0969b6b4db9b586241f5f5bd0dc631096 xsa166-4.5.patch $
Patches have been sent to xen maintainers (GPG).
Bug 68212 relates to the xsa patches listed here that are made for the kernel. All patches of xsa-157 apply to Kernel Linux 4.3. Most patches of xsa-155 The patches of xsa-155 that apply to xensource all take and see it build in xen-tools 4.5, 4.6. They are patches of qemuu and qemut. Ditto xsa164-qemut.patch Patches of xsa165 and xsa166 apply to corresponding versions app-emulation/xen 4.5, 4.6 all take and build effectively.
I have patches of xsa 164,165,166 added to revbumps of xen, xen-tools ready to go. Now these have been combined with 155, 157 and those have been split between the kernel and xen/xen-tools, I have no idea how this is to be managed. If Iwere to add these xsa 164,165,166 to portage now, to my understanding it would require a separate revbump for the rest to be added.
commit 73ce06fe905a06fa25f71fc49cb063d547b6a3f0 Author: Ian Delaney <idella4@gentoo.org> Date: Thu Dec 17 21:40:04 2015 +0800 app-emulation/xen: revbumps to vns. 4.5.2-r3, 4.6.0-r4 security patches added of xsa 164,165,166 re security Bug 567962 Gentoo bug: #567962 commit 4698dd8e9bf104b3dc3d9065a3fb513d7693bda2 Author: Ian Delaney <idella4@gentoo.org> Date: Thu Dec 17 21:35:31 2015 +0800 app-emulation/xen-tools: revbumps to vns. 4.5.2-r3, 4.6.0-r5 security patches added of xsa 164,165,166, and those effecting qemu (4) from xsa-155 re security Bug 567962 Gentoo bug: #567962
CVE for XSA-166 Pending - http://xenbits.xen.org/xsa/
There will be no CVE for XSA-166 "> Was there ever a CVE number assigned to this? No - MITRE came back to use with 'We are not certain a CVE would be appropriate for this issue. We do not normally create CVEs when "it is however believed that there is no issue in practice." However, if you still want us to assign an ID, we will.'"
A fixed version is in the tree. Added to an existing GLSA Request.
This issue was resolved and addressed in GLSA 201604-03 at https://security.gentoo.org/glsa/201604-03 by GLSA coordinator Yury German (BlueKnight).
