A new security bulletin for Qubes OS has been published: QSB-094: x86/AMD: Divide speculative information leak.
QSB-094: x86/AMD: Divide speculative information leak
We have published Qubes Security Bulletin 094: x86/AMD: Divide speculative information leak. The text of this QSB and its accompanying cryptographic signatures are reproduced below. For an explanation of this announcement and instructions for authenticating this QSB, please see the end of this announcement.
---===[ Qubes Security Bulletin 094 ]===--- 2023-09-27 x86/AMD: Divide speculative information leak User action required --------------------- Users must install the following specific packages in order to address the issues discussed in this bulletin: For Qubes 4.1, in dom0: - Xen packages, version 4.14.6-2 For Qubes 4.2, in dom0: - Xen packages, version 4.17.2-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 -------- On 2023-09-25, the Xen Project published XSA-439, "x86/AMD: Divide speculative information leak" [3]: | In the Zen1 microarchitecture, there is one divider in the | pipeline which services uops from both threads. In the case of #DE, | the latched result from the previous DIV to execute will be forwarded | speculatively. | | This is a covert channel that allows two threads to communicate | without any system calls. In also allows userspace to obtain the | result of the most recent DIV instruction executed (even | speculatively) in the core, which can be from a higher privilege | context. For more information, see: * https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7007.html Impact ------- On systems with an AMD Zen (first generation) CPU, an attacker who compromises a VM can attempt to exploit this vulnerability in order to infer the contents of data from a different execution context on the same CPU core. This includes data belonging to a different VM (which could be dom0) that was previously scheduled on that CPU core and Xen itself. The latter is relevant because some system operations require Xen to load data from a VM. This data may or may not be sensitive. However, the attacker has no control over the data that Xen loads (and, to some extent, no knowledge of what was loaded). Credits -------- See the original Xen Security Advisory. References ----------- [1] https://www.qubes-os.org/doc/testing/ [2] https://www.qubes-os.org/doc/how-to-update/ [3] https://xenbits.xen.org/xsa/advisory-439.html -- The Qubes Security Team https://www.qubes-os.org/security/
