|Public release ||2015-03-10 12:00|
|Updated ||2015-03-31 16:13|
|Title ||Non-maskable interrupts triggerable by guests|
Filesadvisory-120.txt (signed advisory file)
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2015-2150 / XSA-120
Non-maskable interrupts triggerable by guests
UPDATES IN VERSION 5
The original patches were incomplete: although they eliminated the
possibility that the guest might disable memory and I/O decoding, they
did not ensure that these bits were set at start of day. The result
was that a malicious guest could simply avoid enabling them and
continue to exploit the vulnerability.
Well behaved guests would normally enable decoding and therefore would
not normally suffer a regression.
Additional patches are now supplied to resolve this issue.
Guests are currently permitted to modify all of the (writable) bits in
the PCI command register of devices passed through to them. This in
particular allows them to disable memory and I/O decoding on the
device unless the device is an SR-IOV virtual function, in which case
subsequent accesses to the respective MMIO or I/O port ranges would
- - on PCI Express devices - lead to Unsupported Request responses. The
treatment of such errors is platform specific.
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
pass-through. Upstream Linux versions 3.1 and onwards are vulnerable
due to supporting PCI backend functionality. Other Linux versions as
well as other OS versions may be vulnerable too.
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 guests.
This issue was discovered by Jan Beulich of SUSE.
Applying the appropriate attached patches resolves this issue for the
indicated versions of Linux, but only for ordinary PCI config space
accesses by the guest. See XSA-124 for all other cases.
xsa120.patch Linux 3.19
xsa120-addendum.patch Linux 3.19
$ sha256sum xsa120*.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