We have just published Qubes Security Bulletin (QSB) #060: Multiple Xen issues (XSA-345, XSA-346, XSA-347). 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).
Special note: Although XSA-345 is included in this QSB, we do not consider XSA-345 to affect the security of Qubes OS, since the default configuration is safe, and we have already implemented appropriate safeguards to prevent users from changing to a vulnerable configuration by accident. Please see the Impact section in QSB #060 below for further details.
View QSB #060 in the qubes-secpack:
Learn about the qubes-secpack, including how to obtain, verify, and read it:
View all past QSBs:
View the associated XSAs in the XSA Tracker:
---===[ Qubes Security Bulletin #60 ]===--- 2020-10-20 Multiple Xen issues (XSA-345, XSA-346, XSA-347) Summary ======== On 2020-10-20, the Xen Security Team published the following Xen Security Advisories (XSAs): XSA-345  "x86: Race condition in Xen mapping code": | The Xen code handling the updating of the hypervisor's own pagetables | tries to use 2MiB and 1GiB superpages as much as possible to maximize | TLB efficiency. Some of the operations for checking and coalescing | superpages take non-negligible amount of time; to avoid potential lock | contention, this code also tries to avoid holding locks for the entire | operation. | | Unfortunately, several potential race conditions were not considered; | precisely-timed guest actions could potentially lead to the code | writing to a page which has been freed (and thus potentially already | reused). | | A malicious guest can cause a host denial-of-service. Data corruption | or privilege escalation cannot be ruled out. XSA-346  "undue deferral of IOMMU TLB flushes": | To efficiently change the physical to machine address mappings of a | larger range of addresses for fully virtualized guests, Xen contains | an optimization to coalesce per-page IOMMU TLB flushes into a single, | wider flush after all adjustments have been made. While this is fine | to do for newly introduced page mappings, the possible removal of | pages from such guests during this operation should not be "optimized" | in the same way. This is because the (typically) final reference of | such pages is dropped before the coalesced flush, and hence the pages | may have been put to a different use even though DMA initiated by | their original owner might still be in progress. | | A malicious guest might be able to cause data corruption and data | leaks. Host or guest Denial of Service (DoS), and privilege | escalation, cannot be ruled out. XSA-347  "unsafe AMD IOMMU page table updates": | AMD IOMMU page table entries are updated in a step by step manner, | without regard to them being potentially in use by the IOMMU. | Therefore it was possible that the IOMMU would read and then use a | half-updated entry. Furthermore, updates to Device Table entries | lacked suitable ordering enforcement for certain steps involved in | these updates. | | In both case the specific outcome heavily depends on how exactly the | compiler translated the affected pieces of code. | | A malicious guest might be able to cause data corruption and data | leaks. Host or guest Denial of Service (DoS), and privilege | escalation, cannot be ruled out. Impact ======= XSA-345: The default Qubes configuration is safe. Shadow mode for HVM and PVH domains is disabled at build time, and domains that have PCI devices run in HVM mode by default. Therefore, we do not consider this XSA to affect the security of Qubes OS. However, we are including it in this QSB anyway since it is technically possible for the user to manually change a domain that has PCI devices from HVM to PV, which would result in a configuration that is vulnerable to this issue. Having anticipated the risk associated with such a manual change, we have already implemented appropriate safeguards. In the Qubes GUI for changing VM settings, the user would have to go to the "Advanced" tab in order to change the setting from HVM to PV. Upon making the change, the user would immediately be confronted with a warning in bold red text that reads, "Using PV mode exposes more hypervisor attack surface!" Therefore, it is nearly impossible users would switch to the vulnerable configuration by accident. XSA-346, XSA-347: A malicious domain with a PCI device (e.g., sys-net or sys-usb in the default configuration) could try to exploit this vulnerability in order to crash the host. Beyond DoS, it is unlikely that this vulnerability could be exploited to compromise the system, but we cannot completely rule out the possibility. Both of these issues apply only to systems running on AMD processors. 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-25 For Qubes 4.1: - Xen packages, version 4.14.0-6 The packages are to be installed in dom0 via the Qube 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 Advisories. References ===========  https://xenbits.xen.org/xsa/advisory-345.html  https://xenbits.xen.org/xsa/advisory-346.html  https://xenbits.xen.org/xsa/advisory-347.html -- The Qubes Security Team https://www.qubes-os.org/security/
This is a companion discussion topic for the original entry at https://www.qubes-os.org/news/2020/10/20/qsb-060/