QSB-083: Retbleed: Arbitrary speculative code execution with return instructions (XSA-407)

We have just published Qubes Security Bulletin (QSB) 083: Retbleed: Arbitrary speculative code execution with return instructions (XSA-407). 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-083 in the qubes-secpack:


In addition, you may wish to:

             ---===[ Qubes Security Bulletin 083 ]===---



                Arbitrary speculative code execution
                 with return instructions (XSA-407)

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-43

  For Qubes 4.1, in dom0:
  - Xen packages, version 4.14.5-6

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

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.


On 2022-07-12, the Xen Project published XSA-407, "Retbleed -
arbitrary speculative code execution with return instructions" [3]:

| Researchers at ETH Zurich have discovered Retbleed, allowing for
| arbitrary speculative execution in a victim context.
| For more details, see:
|   https://comsec.ethz.ch/retbleed
| ETH Zurich have allocated CVE-2022-29900 for AMD and CVE-2022-29901 for
| Intel.
| Despite the similar preconditions, these are very different
| microarchitectural behaviours between vendors.
| On AMD CPUs, Retbleed is one specific instance of a more general
| microarchitectural behaviour called Branch Type Confusion.  AMD have
| assigned CVE-2022-23816 (Retbleed) and CVE-2022-23825 (Branch Type
| Confusion).
| For more details, see:
|   https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1037
| On Intel CPUs, Retbleed is not a new vulnerability; it is only
| applicable to software which did not follow Intel's original
| Spectre-v2 guidance.  Intel are using the ETH Zurich allocated
| CVE-2022-29901.
| For more details, see:
|   https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00702.html
|   https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html
| ARM have indicated existing guidance on Spectre-v2 is sufficient.


This is yet another speculative execution issue, which allows an
attacker to infer content of memory they shouldn't have access to. This
includes one VM extracting secrets from another. Any VM can perform this
attack on an affected hardware.

AMD systems based on Zen 1 - Zen 2 microarchitectures are affected.
Specifically those are AMD Ryzen processors with model names 1xxx - 4xxx
and some 5xxxU [4]. Zen 3 microarchitecture (AMD Ryzen 5xxx or newer)
are not affected.

Pre-existing Xen mitigations on Intel machines are effective to prevent
this issue, so Intel systems are not affected.


See the original Xen Security Advisory.


[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-407.html
[4] Unlike other 5xxxU models, Ryzen 3 5300U, Ryzen 5 5500U and
    Ryzen 7 5700U are Zen 2, not Zen 3. See

The Qubes Security Team

This is a companion discussion topic for the original entry at https://www.qubes-os.org/news/2022/07/13/qsb-083/

Phoronix.com has written an article on the performance cost of the Retbleed mitigation for Linux

Based on that overhead estimation, this smells like “planned obsolescence” on the part of Intel and AMD (I hope it’s not, of course). I’m sure there is someone somewhere in those companies already speculating the revenue increase when everyone with a 4-6th generation Intel and 1-2nd Zen AMD CPU comes running to buy new systems :frowning:

Not cool!

I suspect what occurred is that they internally realized the possibility of there being a vulnerability in the impacted hardware and mitigated the possibility in the next iterations of the lines.

As no one external to them had noticed (yet), they “failed” to report the vulnerability themselves as they didn’t have one in hand: they just had a strong belief but not POC. No POC…no vulnerability.

Internal engineering is probably forbidden by policy (legal department) to attempt to write a POC on a hunch unless a sufficiently documented case comes in from the outside. That way they can say they never technically found the vulnerability.

And also, sorry about the lack of refunds.


Sorry, I’m new enough this is my first time with this sort of thing in Qubes.

Does the dom0 update I got a couple of days ago have anything to do with this? I got the impression I had to do something myself to get the fix, at least for the next couple of weeks.

You can check if you have updated your xen packages to version 4.14.5-6 in dom0:
dnf list | grep xen
Also check your dom0 updates source repository in Qubes Global Settings:

I remember seeing xen in the details for the update. But it looks like it wasn’t for this (I’m showing 5-5). But I believe there was a two-week-old alert that rose to the top of my “feed” here a couple of days ago as well; likely it was for that.

So I can decide whether I want the upgrade now or whether I am content to wait two weeks.

Note that for Intel, only 6-8th gen are affected by RSBA, but newer generations are affected by RRSBA: Affected Processors: Transient Execution Attacks & Related Security...
Though RRSBA is not mentioned in the Xen security advisory, so I wonder if Xen needs an update for that.

Some AMD CPUs need SMT to be disabled as well, so I’m wondering if performance reducing mitigations on other CPUs are needed if SMT/HT is disabled anyway.