We have just published Qubes Security Bulletin (QSB) #059: Multiple Xen issues (XSA-337, XSA-340, XSA-343). 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 #059 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 #59 ]===--- 2020-09-22 Multiple Xen issues (XSA-337, XSA-340, XSA-343) Summary ======== On 2020-09-22, the Xen Security Team published the following Xen Security Advisories (XSAs): XSA-337  "PCI passthrough code reading back hardware registers": | Code paths in Xen's MSI handling have been identified which act on | unsanitized values read back from device hardware registers. While | devices strictly compliant with PCI specifications shouldn't be able | to affect these registers, experience shows that it's very common for | devices to have out-of-spec "backdoor" operations which can affect the | result of these reads. | | A not fully trusted guest may be able to crash Xen, leading to a | Denial of Service (DoS) for the entire system. Privilege escalation | and information leaks cannot be excluded. XSA-340  "Missing memory barriers when accessing/allocating an event channel": | Event channels control structures can be accessed lockless as long as | the port is considered to be valid. Such sequence is missing | appropriate memory barrier (e.g smp_*mb()) to prevent both the | compiler and CPU to re-order access. | | A malicious guest may be able to cause a hypervisor crash resulting in | a Denial of Service (DoS). Information leak and privilege escalation | cannot be excluded. XSA-343  "races with evtchn_reset()": | Uses of EVTCHNOP_reset (potentially by a guest on itself) or | XEN_DOMCTL_soft_reset (by itself covered by XSA-77) can lead to the | violation of various internal assumptions. This may lead to out of | bounds memory accesses or triggering of bug checks. | | In particular x86 PV guests may be able to elevate their privilege to | that of the host. Host and guest crashes are also possible, leading | to a Denial of Service (DoS). Information leaks cannot be ruled out. Impact ======= XSA-337: A malicious HVM with a PCI device (such as sys-net or sys-usb in the default Qubes OS configuration) can potentially compromise the whole system. XSA-340: A malicious VM can exploit this vulnerability to crash Qubes OS, resulting in a Denial of Service (DoS). This would require winning a tight race condition. Beyond DoS, it is very unlikely that this vulnerability could be exploited to compromise the system, but we cannot completely rule out the possibility. XSA-343: By default, Qubes OS uses PV domains only as stubdomains hosting qemu for HVM domains. Therefore, in the default configuration, an adversary cannot exploit this vulnerability directly. However, if an adversary were also able to identify a complementary qemu vulnerability, then chaining the attacks together could theoretically allow the adversary to compromise the whole system. Although Qubes OS does not contain any PV domains by default, users can create them manually by setting the virt_mode property to PV. Such domains can exploit this vulnerability directly. 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-23 For Qubes 4.1: - Xen packages, version 4.14.0-4 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 Advisory. References ===========  https://xenbits.xen.org/xsa/advisory-337.html  https://xenbits.xen.org/xsa/advisory-340.html  https://xenbits.xen.org/xsa/advisory-343.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/09/22/qsb-059/