|Public release ||2015-03-31 12:00|
|Updated ||2015-03-31 12:09|
|Title ||Unmediated PCI command register access in qemu|
Filesadvisory-126.txt (signed advisory file)
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2015-2756 / XSA-126
Unmediated PCI command register access in qemu
UPDATES IN VERSION 3
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
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
Xen versions 3.3 and onwards are vulnerable due to supporting PCI
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.
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.
This issue was discovered by Jan Beulich of SUSE.
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
$ sha256sum xsa126*.patch
DEPLOYMENT DURING EMBARGO
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----
Xenproject.org Security Team