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 ]===---


 Issues with PV type change and handling IOMMU on AMD (XSA-310, XSA-311)


On 2019-12-11, the Xen Security Team published the following Xen
Security Advisories (XSAs):

XSA-310 (CVE-2019-19580) [1] 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) [2] 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.


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

3. Finally, find some way to exploit the vulnerability described in

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.


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.


See the original Xen Security Advisory.


[1] https://xenbits.xen.org/xsa/advisory-310.html
[2] https://xenbits.xen.org/xsa/advisory-311.html

The Qubes Security Team