QSB-070: Xen issues related to grant tables v2 and IOMMU https | Qubes OS📢

QSB-070: Xen issues related to grant tables v2 and IOMMU
https://www.qubes-os.org/news/2021/08/25/qsb-070/

We have just published Qubes Security Bulletin (QSB) 070:
Xen issues related to grant tables v2 and IOMMU.
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-070 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-070-2021.txt

In addition, you may wish to:


Get the qubes-secpack: https://www.qubes-os.org/security/pack/
View all past QSBs: https://www.qubes-os.org/security/qsb/
View the XSA Tracker: https://www.qubes-os.org/security/xsa/




---===[ Qubes Security Bulletin 070 ]===---

2021-08-25


Xen issues related to grant tables v2 and IOMMU
(XSA-378, XSA-379, XSA-382)


User action required
=====================

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

For Qubes 4.0, in dom0:
- Xen packages, version 4.8.5-35

For Qubes 4.1, in dom0:
- Xen packages, version 4.14.2-2

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. [1] Once available, the packages are to be installed
via the Qubes Update Tool or its command-line equivalents. [2]

Dom0 must be restarted afterward in order for the updates to take
effect.

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.


Summary
========

The following security advisories were published on 2021-08-25:

XSA-378 [3] "IOMMU page mapping issues on x86":

| Both AMD and Intel allow ACPI tables to specify regions of memory
| which should be left untranslated, which typically means these
| addresses should pass the translation phase unaltered. While these
| are typically device specific ACPI properties, they can also be
| specified to apply to a range of devices, or even all devices.
|
| On all systems with such regions Xen failed to prevent guests from
| undoing/replacing such mappings (CVE-2021-28694).
|
| On AMD systems, where a discontinuous range is specified by firmware,
| the supposedly-excluded middle range will also be identity-mapped
| (CVE-2021-28695).
|
| Further, on AMD systems, upon de-assigment of a physical device from a
| guest, the identity mappings would be left in place, allowing a guest
| continued access to ranges of memory which it shouldn't have access to
| anymore (CVE-2021-28696).
|

XSA-379 [4] "grant table v2 status pages may remain accessible after
de-allocation":

| Guest get permitted access to certain Xen-owned pages of memory. The
| majority of such pages remain allocated / associated with a guest for
| its entire lifetime. Grant table v2 status pages, however, get
| de-allocated when a guest switched (back) from v2 to v1. The freeing
| of such pages requires that the hypervisor know where in the guest
| these pages were mapped. The hypervisor tracks only one use within
| guest space, but racing requests from the guest to insert mappings of
| these pages may result in any of them to become mapped in multiple
| locations. Upon switching back from v2 to v1, the guest would then
| retain access to a page that was freed and perhaps re-used for other
| purposes.
|
| A malicious guest may be able to elevate its privileges to that of the
| host, cause host or guest Denial of Service (DoS), or cause information
| leaks.

XSA-382 [5] "inadequate grant-v2 status frames array bounds check"
| The v2 grant table interface separates grant attributes from grant
| status. That is, when operating in this mode, a guest has two tables.
| As a result, guests also need to be able to retrieve the addresses that