We have just published Qubes Security Bulletin (QSB) #055: Issues with PV type change and handling IOMMU on AMD (XSA-310, XSA-311). 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 #055 in the qubes-secpack:
Learn about the qubes-secpack, including how to obtain, verify, and read it:
View all past QSBs:
View XSA-310 and XSA-311 in the XSA Tracker:
---===[ Qubes Security Bulletin #55 ]===--- 2019-12-11 Issues with PV type change and handling IOMMU on AMD (XSA-310, XSA-311) Summary ======== On 2019-12-11, the Xen Security Team published the following Xen Security Advisories (XSAs): XSA-310 (CVE-2019-19580)  Further issues with restartable PV type change operations: | XSA-299 addressed several critical issues in restartable PV type | change operations. Despite extensive testing and auditing, some | corner cases were missed. | | A malicious PV guest administrator may be able to escalate their | privilege to that of the host. XSA-311 (CVE-2019-19577)  Bugs in dynamic height handling for AMD IOMMU pagetables: | When running on AMD systems with an IOMMU, Xen attempted to | dynamically adapt the number of levels of pagetables (the pagetable | height) in the IOMMU according to the guest's address space size. The | code to select and update the height had several bugs. | | Notably, the update was done without taking a lock which is necessary | for safe operation. | | A malicious guest administrator can cause Xen to access data | structures while they are being modified, causing Xen to crash. | Privilege escalation is thought to be very difficult but cannot be | ruled out. | | Additionally, there is a potential memory leak of 4kb per guest boot, | under memory pressure. Impact ======= XSA-310 applies only to PV domains. Most of the domains in Qubes 4.0 are PVH or HVM domains and are therefore not affected by XSA-310. However, PV domains are still supported in Qubes 4.0, and they are specifically used to host Qemu-instance-supporting HVM domains. In the default Qubes 4.0 setup, several attacks would have to be chained together in order to exploit this vulnerability. Specifically, an attacker would have to: 1. Take control of an HVM domain, e.g., sys-usb, sys-net, or a user-created HVM domain. (Most user domains are PVH and are therefore not affected.) 2. Successfully attack a Qemu instance running in an associated PV stubdomain. 3. Finally, find some way to exploit the vulnerability described in XSA-310. Moreover, since this vulnerability is a race condition, it is an unreliable attack vector in real world scenarios. XSA-311 affects only systems running on AMD hardware and also is thought to be very hard to exploit. But since it can't be ruled out completely, we recommend applying updates nevertheless. Patching ========= The specific packages that resolve the problems discussed in this bulletin are as follows: For Qubes 4.0: - Xen packages, version 4.8.5-14 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 A system restart will be required afterwards. 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 Advisory. References ===========  https://xenbits.xen.org/xsa/advisory-310.html  https://xenbits.xen.org/xsa/advisory-311.html -- The Qubes Security Team https://www.qubes-os.org/security/