QSB-123: AMD CPU vulnerabilities (XSA-524, XSA-525)

Key points

The Qubes security team published Qubes Security Bulletin 123 on 2026-11-10, covering two Xen advisories for AMD CPUs, XSA-524 and XSA-525. The fixes ship as updated Xen packages for Qubes 4.3 and arrive through normal system updates.

The vulnerabilities

• XSA-524 (AMD IOMMU out-of-bounds Device Table read): under specific circumstances, some AMD IOMMUs read past the Device Table size set by the hypervisor and treat that data as valid device configuration. AMD tracks it as AMD-SB-3060.
• Impact of XSA-524 on Qubes: a malicious qube may be able to write to arbitrary memory pages and compromise the whole system.
• XSA-525 (Transient Scheduler Attacks, update to XSA-471): AMD has corrected its earlier statement that Zen5 CPUs were not vulnerable to TSA-SQ and TSA-L1. This is tracked as AMD-SB-7073 under the existing CVE-2024-36350 and CVE-2024-36357.
• XSA-525 also covers a new variant, TSA-Fill, tracked as AMD-SB-3031 and CVE-2026-0004.
• Impact of XSA-525 on Qubes: a malicious qube may be able to leak data from other qubes.

Who is affected

• XSA-524: some AMD EPYC CPUs, and only with a specific device configuration; the details are in AMD-SB-3060 and XSA-524.
• XSA-525: AMD Zen 5 CPUs.
• Intel CPUs are not affected by either issue.

Patching

• Qubes 4.3: Xen packages version 4.19.6-4 in dom0.
• No special action is needed beyond updating as usual with the Qubes Update tool or its command-line equivalents.
• The packages are first published in the security-testing repositories, which are disabled by default, and move to the stable repositories after community testing. This generally takes one to two weeks, though it may be expedited in urgent cases.
• To get the fix sooner, at the risk of more bugs, security-testing can be enabled temporarily or permanently. Dom0, templates and standalones each have their own security-testing repository.
• After the packages are installed, dom0 must be restarted for the fixes to take effect.
• Anti Evil Maid users must reseal their secret passphrase to new PCR values, because PCR18+19 changes when the Xen binaries are updated.

Verifying the bulletin

• The bulletin is signed by Marek Marczykowski-Górecki and Simon Gaiser (HW42). The project says checking these PGP signatures is the only way to be certain a QSB is authentic.
• The procedure assumes a Linux system with git and gpg: fetch the Qubes Master Signing Key (QMSK), check its fingerprint, clone the qubes-secpack repo, import its keys, verify the signed Git tag, then verify both signatures on the bulletin.
• The expected QMSK fingerprint is 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494, shown by typing fpr at the gpg> prompt.
• The key must be authenticated out-of-band by comparing the fingerprint from several independent sources. Only then set its trust to 5 with trust and quit with q.
• The last line of output from the tag check and from each gpg --verify should begin with "gpg: Good signature from" followed by an appropriate key.
• Alternatively, the bulletin text and both signatures can be copied from the announcement into plain text files and verified the same way.

gpg --fetch-keys https://keys.qubes-os.org/keys/qubes-master-signing-key.asc
gpg --edit-key 0x427F11FD0FAA4B080123F01CDDFA1A3E36879494
git clone https://github.com/QubesOS/qubes-secpack.git
gpg --import qubes-secpack/keys/*/*
cd qubes-secpack/
git tag -v `git describe`
cd QSBs/
gpg --verify qsb-123-2026.txt.sig.marmarek qsb-123-2026.txt
gpg --verify qsb-123-2026.txt.sig.simon qsb-123-2026.txt

Summary by DistroNews, based on the original post.