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:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-059-2020.txt

Learn about the qubes-secpack, including how to obtain, verify, and read it:

https://www.qubes-os.org/security/pack/

View all past QSBs:

https://www.qubes-os.org/security/bulletins/

View the associated XSAs in the XSA Tracker:

https://www.qubes-os.org/security/xsa/#337
https://www.qubes-os.org/security/xsa/#340
https://www.qubes-os.org/security/xsa/#343



             ---===[ 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 [1] "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 [2] "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 [3] "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
===========

[1] https://xenbits.xen.org/xsa/advisory-337.html
[1] https://xenbits.xen.org/xsa/advisory-340.html
[1] https://xenbits.xen.org/xsa/advisory-343.html

--
The Qubes Security Team
https://www.qubes-os.org/security/