Information

AdvisoryXSA-302
Public release 2019-10-31 12:00
Updated 2019-10-31 12:30
Version 5
CVE(s) CVE-2019-18424
Title passed through PCI devices may corrupt host memory after deassignment

Files

advisory-302.txt (signed advisory file)
xsa302.meta
xsa302-4.9/0001-IOMMU-add-missing-HVM-check.patch
xsa302-4.9/0002-passthrough-quarantine-PCI-devices.patch
xsa302-4.10/0001-IOMMU-add-missing-HVM-check.patch
xsa302-4.10/0002-passthrough-quarantine-PCI-devices.patch
xsa302-4.11/0001-IOMMU-add-missing-HVM-check.patch
xsa302-4.11/0002-passthrough-quarantine-PCI-devices.patch
xsa302-4.12/0001-IOMMU-add-missing-HVM-check.patch
xsa302-4.12/0002-passthrough-quarantine-PCI-devices.patch
xsa302/0001-passthrough-quarantine-PCI-devices.patch

Advisory


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2019-18424 / XSA-302
                               version 5

 passed through PCI devices may corrupt host memory after deassignment

UPDATES IN VERSION 5
====================

Public release.

The patches are broken on ARM (which is not affected by the issue).
Don't apply the patches on ARM.  See Resolution.

ISSUE DESCRIPTION
=================

When a PCI device is assigned to an untrusted domain, it is possible
for that domain to program the device to DMA to an arbitrary address.
The IOMMU is used to protect the host from malicious DMA by making
sure that the device addresses can only target memory assigned to the
guest. However, when the guest domain is torn down, or the device is
deassigned, the device is assigned back to dom0, thus allowing any
in-flight DMA to potentially target critical host data.

IMPACT
======

An untrusted domain with access to a physical device can DMA into host
memory, leading to privilege escalation.

VULNERABLE SYSTEMS
==================

Only systems where guests are given direct access to physical devices
capable of DMA (PCI pass-through) are vulnerable.  Systems which do
not use PCI pass-through are not vulnerable.

MITIGATION
==========

In some configurations, use of passthrough can be replaced with a
higher-level protocol such as Xen PV block or network devices.

CREDITS
=======

This issue was discovered by Paul Durrant of Citrix.

RESOLUTION
==========

Applying the appropriate attached patchset should resolve this issue.
For Xen 4.9 and earlier at least the first patch of XSA-299
(whitespace cleanup) is also needed for XSA-302 to apply.

Unfortunately, at the time of writing, these patches have not been
tested to our satisfaction.

The patches are known to break on ARM.  ARM is not affected by the
issue, so do not apply these patches on ARM systems.  (On x86, there
is a latent bug but the patches are good to use.)

xsa302/*.patch         xen-unstable
xsa302-4.12/*.patch    Xen 4.12.x
xsa302-4.11/*.patch    Xen 4.11.x
xsa302-4.10/*.patch    Xen 4.10.x
xsa302-4.9/*.patch     Xen 4.9.x, Xen 4.8.x

$ sha256sum xsa302* xsa302*/*
d722d1bed2440a5d35f0fd041e4a77966b7d26980a0f874d38d48710db0b9ebd  xsa302.meta
703faced133ca21142f484acd8cf16578258e12ae0cf1413a5d9252f1e099465  xsa302-4.9/0001-IOMMU-add-missing-HVM-check.patch
edb4753b91fa66e2f4b51d0075d106fc28d8451241ba482a33c2db4be53f21d1  xsa302-4.9/0002-passthrough-quarantine-PCI-devices.patch
3c79107d8fd94807543443192fb31f3d188912c208f4dbda61f1f2ff92701afc  xsa302-4.10/0001-IOMMU-add-missing-HVM-check.patch
2a76add5a907baf0217e57e2a4dca91a6a8ce84c67b9ff87be1bcbb1f29efdc6  xsa302-4.10/0002-passthrough-quarantine-PCI-devices.patch
a75723160c52c2c65d563905d0904b587beda1cfb6ca3ee18fb70e79818d3faa  xsa302-4.11/0001-IOMMU-add-missing-HVM-check.patch
48b9dae7adbe2438dcaa00f969532d835061cb4a06ab2bf47ada2afb644de4c5  xsa302-4.11/0002-passthrough-quarantine-PCI-devices.patch
a21efa6cae14e87318ca3927f0ac310aee2dd1323f2dbf040c0fe80789d78712  xsa302-4.12/0001-IOMMU-add-missing-HVM-check.patch
0a95f750ad1d5eb1838b6488e4ac188acdc2e568eb21b26306d5af2980bffb58  xsa302-4.12/0002-passthrough-quarantine-PCI-devices.patch
11d7015960eab265b1f9ce372dd14597b6c4cc7907d77ed3eed14d161dd50e5c  xsa302/0001-passthrough-quarantine-PCI-devices.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the *patches* described above (or others which are
substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Also: deployment of the reconfiguration *mitigation* is NOT permitted
(except where all the affected systems and VMs are administered and
used only by organisations which are members of the Xen Project
Security Issues Predisclosure List).  Specifically, deployment on
public cloud systems is NOT permitted.

This is because this reconfiguration reveals that a PCI passthrough
vulnerability is involved.

Deployment of that migitation is permitted only AFTER the embargo
ends.

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(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:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl260/wMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ2TYH/A+tmA2Wsw0NbdEhSzztj6cVFZpev16S75vOxLUm
/dFTQSxNVeqyzZjI7u9JPZUatQVIHwdDPi9Oiwygn8pFid1RBe+fn3saM3JdNQrA
pYVOCEYGoxnz/lpPLWfcI8aUIkdhU4Ns/hwXVa6lUNno9MaqqJR278k6nmB9/0QS
bFvsMirqTKHm7wQptY5mRcULdjcpn+u4W45nje3+TU0mMRQkbm+pnNX57qzn/LFI
/atzBQ8iyv9/y3e/soAXv3AkWzs/lUVIAZepaFhXCHi3WuMsMUyZAdDOUBmD0tBt
pjQzx408ZoMPtqqDKpY1qEn9Bu1MsIxx/4htqlgG0c9Kh1U=
=cUbr
-----END PGP SIGNATURE-----


Xenproject.org Security Team