2021-06-09 05:08:31
QSB-069: Multiple Xen and Intel issues
https://www.qubes-os.org/news/2021/06/08/qsb-069/
We have just published Qubes Security Bulletin (QSB) 069:
Multiple Xen and Intel issues.
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-069 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-069-2021.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/
---===[ Qubes Security Bulletin 069 ]===---
2021-06-08
Multiple Xen and Intel issues
(XSA-373, XSA-374, XSA-375, XSA-377, INTEL-SA-00442)
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-34
- Linux kernel packages, versions 5.12.9-1 (for users of the "latest"
kernel flavor)
- microcode_ctl package, version 2.1-33.qubes1 (for Intel CPU users)
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.1-5
- Linux kernel packages, versions 5.10.42-1, 5.12.9-1 (for users of
the "latest" kernel flavor)
- microcode_ctl package, version 2.1-33.qubes1 (for Intel CPU users)
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-06-08:
XSA-373 [3] "Inappropriate x86 IOMMU timeout detection / handling":
| IOMMUs process commands issued to them in parallel with the operation
| of the CPU(s) issuing such commands. In the current implementation in
| Xen, asynchronous notification of the completion of such commands is
| not used. Instead, the issuing CPU spin-waits for the completion of
| the most recently issued command(s). Some of these waiting loops try
| to apply a timeout to fail overly-slow commands. The course of action
| upon a perceived timeout actually being detected is inappropriate:
| - on Intel hardware guests which did not originally cause the timeout
| may be marked as crashed,
| - on AMD hardware higher layer callers would not be notified of the
| issue, making them continue as if the IOMMU operation succeeded.
XSA-374 [4] "Guest triggered use-after-free in Linux xen-netback":
| A malicious or buggy network PV frontend can force Linux netback to
| disable the interface and terminate the receive kernel thread
| associated with queue 0 in response to the frontend sending a
| malformed packet.
|
| Such kernel thread termination will lead to a use-after-free in Linux
| netback when the backend is destroyed, as the kernel thread associated
| with queue 0 will have already exited and thus the call to
| kthread_stop will be performed against a stale pointer.
XSA-375 [5] "Speculative Code Store Bypass":
| Modern superscalar processors may employ sophisticated decoding and
| caching of the instruction stream to improve performance. However, a
| consequence is that self-modifying code updates may not take effect
| instantly.
|
| Whatever the architectural guarantees, some CPUs have
| microarchitectural behaviour whereby the stale instruction stream may
| be speculatively decoded and executed.
|
| Speculation of this form can suffer from type confusion in registers,
| and potentially leak data.
12 views02:08
Q
