|Public release ||2013-02-05 12:00|
|Updated ||2013-02-21 11:05|
|Title ||interrupt remap entries shared and old ones not cleared on AMD IOMMUs|
Filesadvisory-36.txt (signed advisory file)
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2013-0153 / XSA-36
interrupt remap entries shared and old ones not cleared on AMD IOMMUs
UPDATES IN VERSION 4
Updated patches, to deal with a boot time crash resulting from the earlier
changes on systems with firmware broken in a way not previously accounted
To avoid an erratum in early hardware, the Xen AMD IOMMU code by
default chooses to use a single interrupt remapping table for the
whole system. This sharing implies that any guest with a passed
through PCI device that is bus mastering capable can inject interrupts
into other guests, including domain 0.
Furthermore, regardless of whether a shared interrupt remapping table
is in use, old entries are not always cleared, providing opportunities
(which accumulate over time) for guests to inject interrupts into
other guests, again including domain 0.
In a typical Xen system many devices are owned by domain 0 or driver
domains, leaving them vulnerable to such an attack. Such a DoS is
likely to have an impact on other guests running in the system.
A malicious domain which is given access to a physical PCI device can
mount a denial of service attack affecting the whole system.
Xen versions 3.3 onwards are vulnerable. Earlier Xen versions do not
implement interrupt remapping, and hence do not support secure AMD-Vi
PCI passthrough in any case.
Only systems using AMD-Vi for PCI passthrough are vulnerable.
Any domain which is given access to a PCI device can take advantage of
This issue can be avoided by not assigning PCI devices to untrusted
In Xen versions 4.1.3 and above the sharing of the interrupt remapping
table (and hence the more severe part of this problem) can be avoided
by passing "iommu=amd-iommu-perdev-intremap" as a command line option
to the hypervisor. This option is not fully functional on earlier
Applying the appropriate attached patch resolves this issue.
Note that on certain systems (SP5100 chipsets with erratum 28 present,
or such with broken IVRS ACPI table) these patches will result in the
IOMMU not being enabled anymore. This should be dealt with by a BIOS
update, if available. Alternatively the check can be overridden by
specifying "iommu=no-amd-iommu-perdev-intremap" on the Xen command
line ("iommu=amd-iommu-global-intremap" on 4.1.x), at the price of
re-opening the security hole addressed by these patches.
xsa36-unstable.patch Xen unstable
xsa36-4.2.patch Xen 4.2.x
xsa36-4.1.patch Xen 4.1.x
$ sha256sum xsa36*.patch
Incremental patches on top of what was provided in version 3 can also be
taken from the respective mercurial trees:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
-----END PGP SIGNATURE-----
Xenproject.org Security Team