We have just published Qubes Security Bulletin (QSB) #054: Xen fix for XSA-302 found ineffective in Qubes configuration (XSA-306). The text of this QSB is reproduced below. This QSB and its accompanying signatures will always be available in the Qubes Security Pack (qubes-secpack).
View QSB #054 in the qubes-secpack:
Learn about the qubes-secpack, including how to obtain, verify, and read it:
View all past QSBs:
View XSA-306 in the XSA Tracker:
---===[ Qubes Security Bulletin #54 ]===--- 2019-11-26 Xen fix for XSA-302 found ineffective in Qubes configuration (XSA-306) Summary ======== In the course of re-verifying the fixes for QSB #52 (XSA-299, XSA-302) , the Qubes Security Team discovered that the fix released by the Xen Project for XSA-302  is not effective for the configuration used in Qubes OS. On 2019-11-26, the Xen Security Team published the following Xen Security Advisory (XSA): XSA-306  "Device quarantine for alternate pci assignment methods": | XSA-302 relies on the use of libxl's "assignable-add" feature to | prepare devices to be assigned to untrusted guests. | | Unfortunately, this is not considered a strictly required step for | device assignment. The PCI passthrough documentation on the wiki | describes alternate ways of preparing devices for assignment, and | libvirt uses its own ways as well. Hosts where these "alternate" | methods are used will still leave the system in a vulnerable state | after the device comes back from a guest. | | An untrusted domain with access to a physical device can DMA into host | memory, leading to privilege escalation. Impact ======= The original XSA-302 fix provided by the Xen Project is ineffective for the configuration used in Qubes OS. Therefore, the impact is the same as as the XSA-302 impact originally reported in QSB #52 (XSA-299, XSA-302). Discussion =========== The Qubes Security Team discovered this issue while re-verifying the Xen Project's fixes for XSA-302. At that time, both XSA-302 and QSB #52 had already been made public. Whether a disclosure has been made public is significant to the Xen Security Policy . Therefore, after discussion with the Xen Security Team, we have decided to treat this as a separate security issue, with a separate XSA, QSB, and embargo period. From a security perspective, the new proposed fix for PCI device isolation is much less fragile, since it no longer depends on toolstack (libxl) behavior anymore. Patching ========= The specific packages that resolve the problems discussed in this bulletin are as follows: For Qubes OS 4.0: - Xen packages version 4.8.5-13 The packages are to be installed in dom0 via the Qubes VM Manager or via the qubes-dom0-update command as follows: For updates from the stable repository (not immediately available): $ sudo qubes-dom0-update For updates from the security-testing repository: $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing These packages will migrate from the security-testing repository to the current (stable) repository over the next two weeks after being tested by the community. If you use Anti Evil Maid, you will need to reseal your secret passphrase to new PCR values, as PCR18+19 will change due to the new Xen binaries. Credits ======== See the original Xen Security Advisories. References ===========  https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-052-2019.txt  https://xenbits.xen.org/xsa/advisory-302.html  https://xenbits.xen.org/xsa/advisory-306.html  https://xenproject.org/developers/security-policy/ -- The Qubes Security Team https://www.qubes-os.org/security/