#1109035 amd64-microcode: 2024-36350/TSA-SQ and CVE-2024-36357/TSA-L1

Package:
src:amd64-microcode
Source:
src:amd64-microcode
Submitter:
Salvatore Bonaccorso
Date:
2026-01-09 05:31:02 UTC
Severity:
normal
Tags:
#1109035#5
Date:
2025-07-10 07:12:23 UTC
From:
To:
Hi Henrique,

The following vulnerabilities were published for amd64-microcode.

CVE-2024-36350[0]:
| A transient execution vulnerability in some AMD processors may allow
| an attacker to infer data from previous stores, potentially
| resulting in the leakage of privileged information.


CVE-2024-36357[1]:
| A transient execution vulnerability in some AMD processors may allow
| an attacker to infer data in the L1D cache, potentially resulting in
| the leakage of sensitive information across privileged boundaries.

My understanding from the patch levels in amd-ucode/README is that we
are not yet covered by the needed updates on microcode side[2] for
CVE-2024-36350/TSA-SQ and CVE-2024-36357/TSA-L1 in
amd64-microcode/3.20250311.1. Correct?

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-36350
https://www.cve.org/CVERecord?id=CVE-2024-36350
[1] https://security-tracker.debian.org/tracker/CVE-2024-36357
https://www.cve.org/CVERecord?id=CVE-2024-36357
[2] https://www.amd.com/content/dam/amd/en/documents/resources/bulletin/technical-guidance-for-mitigating-transient-scheduler-attacks.pdf

Regards,
Salvatore

#1109035#12
Date:
2025-07-19 20:59:33 UTC
From:
To:
Hi Henrique,

If not wrong, those updates might be included in
https://gitlab.com/kernel-firmware/linux-firmware/-/commit/331eac9144402d6cfa02ff3b2888a40bb9a7a01a

Is this correct?

Regards,
Salvatore

#1109035#17
Date:
2025-07-30 11:57:31 UTC
From:
To:
#1109035#22
Date:
2025-07-31 20:48:49 UTC
From:
To:
Hello Salvatore,

I will look into it soon, but I am swamped with work so it could take a week or two for me to upload anything .

As far as I know, we cannot update much of the AMD fleet (computers that did not get firmware updates to switch to the new microcode signature track) anyway, so I will also need to check if this changed somehow, etc.

#1109035#27
Date:
2025-07-31 21:18:43 UTC
From:
To:
Hi Henrique,

Thanks for your reply and yes that is absolutely fine. We should in
any case anyhow follow an up-down stragegy so with focus on unstable.

At that time then trixie will be released (on 9th of August), and we
can have a look at trixie and bookworm either via a DSA or the next
upcoming point releases.

Thanks for all your hard and tireless work on this complex front :)

Regards,
Salvatore

#1109035#32
Date:
2025-09-06 13:20:58 UTC
From:
To:
Hi Henrique,

just wondering if you have found time to take a look a this already,
or if there is something I could help you with?
a week or two for me to upload anything .
that did not get firmware updates to switch to the new microcode
signature track) anyway, so I will also need to check if this changed
somehow, etc.

Maybe a stupid question, does that mean we cannot update the microcode
if the firmware (bios?) hasn't been updated?

Regarding the bits in the kernel source Salvatore mentioned above, does
that mean that a minimum kernel is required as well?

(I'm thinking if this might be a problem for (E)LTS..

#1109035#37
Date:
2025-09-06 13:51:39 UTC
From:
To:
Hi,

The situation is complicated, thus you have not seen an update in any
suite so far, so please make sure as well LTS and ELTS do not push
updates before things happens top-down please.

Just to be clear, it is not a dependency thing. For the TSA
mitigations simply both bits are necessary. All kernels 6.15.6,
6.12.37, 6.6.97, 6.1.144 and 5.10.240 onwards have the kernel side
bits, so but the next bullseye-security upload from Ben for 5.10.y
have the mitigations.  OTOH the TSA issue affect only specific AMD
CPUs, so the older suite you go back less relevant is actually the
problem.

Regards,
Salvatore

#1109035#42
Date:
2025-09-14 02:40:00 UTC
From:
To:
Hello Tobias,

Exactly.  You try to load the new microcode into a processor booted from an older BIOS, it throws a #GP.   You try to load the old microcode on a processor with the new BIOS, it throws a #GP (the kernel avoids *this* one by refusing to attempt microcode revision downgrades).  New firmware is required to switch the entire system into the new signature scheme, this has been pretty clear from day one, although *why* isn't exactly explained anywhere I could find.

So, the practical issue is how we keep systems with outdated firmware in the 20250311 release, while shipping new releases to the systems with newer firmware.

The bad news is that, unless I misunderstood the kernel code (and there *is* a good chance I did, let's be hopeful), it will try to update the kernel with *just* the newest revision it is given, and the firmware data files / early initramfs files are *not* different for old and new signature scheme.

I just asked AMD about it, hopefully they will have good news for us.

Now, assuming I did not fail to notice something kernel-side, we would have to detect what microcode track we need to use to generate the initramfs (with all the issues this causes for the installer and live images, etc), or have a legacy package (which is *almost* the same as giving up on the users that need it, as the UX will be horrible, but it is something we can do very easily and safely).

So, let's wait for AMD's response.

#1109035#47
Date:
2025-09-20 13:04:19 UTC
From:
To:
AMD is working on it, and it will be a proper solution with good UX, where the kernel will do the right thing when we send it microcode update data for both old and new BIOSes.

Meanwhile, users on new BIOS can directly download the data files from linux-firmware and replace the ones in their systems, and run update-iniramfs -u (or dracut, etc).

#1109035#52
Date:
2025-11-09 21:14:23 UTC
From:
To:
AMD changes to avoid regressing outdated family 19h systems have showed up on linux-firmware recently, and there are patches to the kernel microcode driver on their way to mainline (they can be seen on the "tip" tree).

I am packaging the new microcode update to upload to *unstable*, but systems with outdated firmware are supposed to regress unless they also have the kernel changes, so updates to stable are still in the future.

It has also become very clear that:

1. Family 0x19 (Zen 2 to Zen 4) will have the choice of staying on the last Entrysign-vulnerable microcode release.  Obviously, they will remain vulnerable to Entrysign and everything else fixed since Entrysign, since they will *not* receive any new microcode updates.

2. Zen 5 systems have no such choice: all systems must update the firmware to fix Entrysign in order to receive microcode updates.

We can issue partial security updates to stable covering only family 0x1a (Zen 5) while we wait for the kernel-side changes that will enable us to ship the fixes for family 0x19 without regressing systems with outdated firmware.

#1109035#59
Date:
2025-12-06 15:48:46 UTC
From:
To:
We believe that the bug you reported is fixed in the latest version of
amd64-microcode, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1109035@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Henrique de Moraes Holschuh <hmh@debian.org> (supplier of updated amd64-microcode package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 06 Dec 2025 12:04:29 -0300
Source: amd64-microcode
Architecture: source
Version: 3.20251202.1
Distribution: unstable
Urgency: medium
Maintainer: Henrique de Moraes Holschuh <hmh@debian.org>
Changed-By: Henrique de Moraes Holschuh <hmh@debian.org>
Closes: 1101350 1109035 1110987 1120005
Changes:
 amd64-microcode (3.20251202.1) unstable; urgency=medium
 .
   * Update package data from linux-firmware 20251202
     * ATTENTION: regression risk if backported to stable or LTS.
       The amd processor microcode updates in this release will not load on
       systems with outdated BIOS vulnerable to "Entrysign" unless a number of
       kernel patches are present.
     * amd-tee: update AMD PMF TA Firmware to v3.1.
     * amd-ucode: update with release 2025-12-02:
       + SECURITY UPDATE (AMD-SB-7055 / CVE-2025-62626)
         Fix RDSEED Failure on more AMD Zen 5 Processor models
         (closes: #1120005)
     * amd-ucode: update with release 2025-11-13:
       + SECURITY UPDATE (AMD-SB-7055 / CVE-2025-62626)
         Fix RDSEED Failure on more AMD Zen 5 Processor models
     * amd-ucode: update with release 2025-10-30:
       + SECURITY UPDATE (AMD-SB-7055 / CVE-2025-62626)
         Fix RDSEED Failure on some AMD Zen 5 Processor models
     + amd-ucode: update with release 2025-10-27:
       * This is the final microcode release for systems that have not
         been updated to fix vulnerability AMD-SB-7033 "Entrysign").
       * A kernel update is needed for the microcode driver to be able
         to select the appropriate microcode updates for outdated system
         firmware vulnerable to "Entrysign".
       * On non-updated kernels, this will potentially *regress* the
         microcode version on the running system back to the one in the
         (outdated, unpatched-for-Entrysign) BIOS.
     + amd-ucode: update with release 2025-07-29:
       + SECURITY UPDATE (AMD-SB-7029: CVE-2024-36350, CVE-2024-36357):
         Mitigate transient execution vulnerabilities in some AMD processors
         which might allow an attacker to infer data from previous stores
         (TSA-SQ) or data in the L1D cache (TSA-L1), potentially resulting in
         the leakage of privileged information and sensitive information across
         priviledged boundaries (closes: #1109035)
       * NOTE: Requires kernel and hypervisor changes for the security
         mitigations to be applied (issue VERW instruction at appropriate
         times).
   * initramfs: guard against copying non-microcode data into the
     early-initramfs bundle, for the benefit of those that copy all files from
     linux-firmware into /lib/firmware/*.  Thanks to Eric Valette for tracking
     it down (closes: #1101350)
   * debian/control: recommend cpio (closes: #1110987)
   * NEWS.Debian: update for post-Entrysign microcode updates
     Document that kernel patches are needed to avoid regressing the microcode
     release on vulnerable Zen2/3/4 systems (family 0x19), and also that these
     systems will not receive any future microcode updates.
Checksums-Sha1:
 88199f24dd54604166dbb04f47b4a263c0fb4292 1716 amd64-microcode_3.20251202.1.dsc
 3424ce8d6b278792d13eab59eeec93994e750ee1 445344 amd64-microcode_3.20251202.1.tar.xz
 17be9261de885f70b384ccaf4578580934ecbbab 5788 amd64-microcode_3.20251202.1_amd64.buildinfo
Checksums-Sha256:
 bfc0ff51d9482e90ddb1d24b888e7ed44f5d2bc13b13c928faba4e743b3a1760 1716 amd64-microcode_3.20251202.1.dsc
 df83c9de9bca9d351b20ec9f550884ababce8f376502bb0f58ee201d564261fe 445344 amd64-microcode_3.20251202.1.tar.xz
 0e58a22e098ea4c245241f24e1632f257f82278b7f7311bd2e2e18a9e81a2c5a 5788 amd64-microcode_3.20251202.1_amd64.buildinfo
Files:
 ea64dcf9e92d673bd4e02848c363f589 1716 non-free-firmware/admin standard amd64-microcode_3.20251202.1.dsc
 be3c290005cd452c82b3af23d6a53c6e 445344 non-free-firmware/admin standard amd64-microcode_3.20251202.1.tar.xz
 6363ab7ab8b694ae664e06a93b5a4dd0 5788 non-free-firmware/admin standard amd64-microcode_3.20251202.1_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJDBAEBCgAtFiEEpvbMGUAhfu+gsYOwlOXoPKamj0cFAmk0SZYPHGhtaEBkZWJp
YW4ub3JnAAoJEJTl6Dympo9He+AP/jlYk0RwB2JziGRicS242C0trW/a6PS++9P6
TUJq/2K//HqhmR9C45YovMwkI7WEQtoPILyWC5UihdCLblTeu7zMJ1Dw38yK8Xog
kQEusrQmMx1++e0Aflrx5SfjinbN8Xk62Yr7vgJFwth3xlKwx0CHhwIYU5JqfhAX
wPxUapniTFrIaHRvT3momXMIzUD7ZKvAE+5zm483u1eQE/6J7LlJkdHJkMnTFWPL
jcAtlo4a9xOaTfmsd+ZJVaFw4iSiNqWQiZK9GnKVOLSkWE8Q5E6ythjxZbmj4FlK
tzMU1SbTkUt9CffeaW+KQ9jc7MSUWoYNPC2rM76mXf1pSTGuq9LDXMUhL+nhqoEP
K8kIHHfSaJQL7IcDF+qGuCX05UxSAfCDOJ4bKbXXsfK2qf33C88p+5f9uVaNATcc
f5kx2m0fXEWgMOhp+XmL5B0PchcY8VfkRuM0lFYQYW2rsg8VKpcWrBfnM+KEUuWh
sG0yg4psiPx1zGZsgp+jN3pI6sgMKtQyBmAbA+1F8dlZ6UPVCbTKo5d8HUFkYh/G
y8vhw3JC0rvN6ZZgnnh2qeeJsIrIMLbexO3FKsx7ZfLutDe9m+V2CFfNjcY5poZL
868wraj89YbiUo1BILMiRTeIN9atkgSt54GTBLiov3y9U8jM9kKsaM6OSIMOMwTN
glb6H25l
=JSpY
-----END PGP SIGNATURE-----

#1109035#64
Date:
2026-01-01 20:01:22 UTC
From:
To:
hi Henrique,

I pondered your mail for a while now.

I think there is no urgency to do a partial update and we can look
forward if and when the changes will trickle into stable series
upstream (if at all). The relevant series for the changes only entered
v6.19-rc1 so far.

In particular as the older back we go, Zen 5 Linux support get less
relevant, so it does make less sense to issue updates with only that
part, well maybe as stable-proposed-update indeed for trixie and
6.12.y based kernel but not older (not considering backports kernel).

Regards,
Salvatore

#1109035#69
Date:
2026-01-09 05:29:11 UTC
From:
To:
Hi,
microcode patch to load") has now been backported to 6.18.4 and
6.12.64.

The Linux upload to unsable will come soon, 6.12.64 an later can be
expected latest on the 13.4 point release for trixie.

Regards,
Salvatore