Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 567962 (CVE-2015-8550) - <app-emulation/xen-{4.5.2-r3,4.6.0-r4}: Multiple vulnerabilities (XSA-{155,157,164,165,166}) (CVE-2015-{8550,8551,8552,8554,8555})
Summary: <app-emulation/xen-{4.5.2-r3,4.6.0-r4}: Multiple vulnerabilities (XSA-{155,15...
Alias: CVE-2015-8550
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
Whiteboard: B3 [glsa cve]
Depends on: CVE-2015-8551, CVE-2015-8552, XSA-155, XSA-157
  Show dependency tree
Reported: 2015-12-11 05:37 UTC by Yury German
Modified: 2016-04-05 07:01 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Yury German Gentoo Infrastructure gentoo-dev 2015-12-11 05:37:32 UTC
Xen Security Advisory XSA-155
                              version 3

    paravirtualized drivers incautious about shared memory contents

              *** EMBARGOED UNTIL 2015-12-17 12:00 UTC ***


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.


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.


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.


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.


There is no mitigation.


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

Please note that there is a bug in some versions of gcc, 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:
Linux v4.[0,1,2,3]
All the above patches except #5 will apply, please use:
Linux v3.19:
All the above patches except #5 and #6 will apply, please use:



NetBSD 7.0:


xen 4.4:
All patches except #3 will apply, please use:

$ 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 ***


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.


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.


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


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.


Applying the appropriate attached patch resolves this issue.

Linux 4.3:

$ 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 ***


"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.


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.


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.


Not passing through MSI-X capable devices to HVM guests will avoid this

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.


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
Comment 1 Yury German Gentoo Infrastructure gentoo-dev 2015-12-11 05:38:51 UTC

                    Xen Security Advisory XSA-165

         information leak in legacy x86 FPU/XMM initialization

              *** EMBARGOED UNTIL 2015-12-17 12:00 UTC ***


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.


A malicious domain may be able to leverage this to obtain sensitive
information such as cryptographic keys from another domain.


All Xen versions are vulnerable.

Only x86 systems without XSAVE support or with XSAVE support disabled
are vulnerable.

ARM systems are not vulnerable.


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.


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 ***


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.


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

Privilege escalation, host crash (Denial of Service), and leaked
information all cannot be excluded.


All Xen versions are affected.

Only x86 variants of Xen are susceptible.  ARM variants are not

Only HVM guests expose this vulnerability.


Running only PV guests will avoid this issue.


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
Comment 2 Yury German Gentoo Infrastructure gentoo-dev 2015-12-11 05:39:51 UTC
Patches have been sent to xen maintainers (GPG).
Comment 3 Ian Delaney (RETIRED) gentoo-dev 2015-12-14 14:51:44 UTC
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.
Comment 4 Ian Delaney (RETIRED) gentoo-dev 2015-12-17 12:32:09 UTC
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.
Comment 5 Ian Delaney (RETIRED) gentoo-dev 2015-12-22 04:20:32 UTC
commit 73ce06fe905a06fa25f71fc49cb063d547b6a3f0
Author: Ian Delaney <>
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 <>
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
Comment 6 Yury German Gentoo Infrastructure gentoo-dev 2015-12-24 16:09:18 UTC
CVE for XSA-166 Pending -
Comment 7 Yury German Gentoo Infrastructure gentoo-dev 2015-12-24 16:36:35 UTC
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.'"
Comment 8 Yury German Gentoo Infrastructure gentoo-dev 2016-02-25 06:34:36 UTC
A fixed version is in the tree. 
Added to an existing GLSA Request.
Comment 9 GLSAMaker/CVETool Bot gentoo-dev 2016-04-05 07:01:58 UTC
This issue was resolved and addressed in
 GLSA 201604-03 at
by GLSA coordinator Yury German (BlueKnight).