AMD warns of new Meltdown, Spectre-like bugs affecting CPUs
- Reference: 1752081432
- News link: https://www.theregister.co.uk/2025/07/09/amd_tsa_side_channel/
- Source link:
Akin to [1]Meltdown and Spectre , the Transient Scheduler Attack (TSA) comprises four vulnerabilities that AMD said it discovered while looking into a Microsoft report about microarchitectural leaks.
The four bugs do not appear too venomous at face value – two have medium-severity ratings while the other two are rated "low." However, the low-level nature of the exploit's impact has nonetheless led Trend Micro and CrowdStrike to assess the threat as "critical."
[2]
The reasons for the low severity scores are the high degree of complexity involved in a successful attack – AMD said it could only be carried out by an attacker able to run arbitrary code on a target machine.
[3]
[4]
It affects AMD processors (desktop, mobile and datacenter models), including 3rd gen and 4th gen EPYC chips – the full list is [5]here .
From AMD:
The vulnerabilities in brief
[6]CVE-2024-36350 (5.6)
[7]CVE-2024-36357 (5.6)
[8]CVE-2024-36348 (3.8)
[9]CVE-2024-36349 (3.8)
They would need local access to the machine, either through a piece of malware or a malicious VM, but the attacks require only low privileges to succeed.
In AMD's view, the TSAs affecting its chips are not exploitable via malicious websites, and would need to be executed many times in order to reliably exfiltrate any data.
[10]
This is because the attack hinges on false completions, which occur when CPUs expect load instructions to complete quickly but a condition prevents them from completing successfully.
Since the load did not complete, the data associated with that load could be forwarded to dependent operations, potentially affecting the timing of instructions being executed by the CPU in a way that attackers could see.
In the worst-case scenarios enabled by the two medium-severity vulnerabilities, successful attacks on AMD chips could lead to information leakage of the OS kernel. Other scenarios could see applications or VMs leaking data too.
[11]
The low-severity bugs could lead to internal CPU operational details being leaked, a type of data AMD doesn't deem to be sensitive.
Access to kernel data could potentially allow attackers to escalate privileges, bypass security mechanisms, establish persistence, and more. AMD's technical report is [12]here [PDF].
Double trouble
AMD said there are two different TSA variants that can feasibly be executed on its chips. It calls them TSA-L1 and TSA-SQ because they refer to side-channel attacks that can infer data from the L1 cache and CPU store queue respectively.
According to AMD's [13]technical documentation [PDF] about its findings, TSA-L1 vulnerabilities are caused by an error in the way the L1 cache uses microtags for lookups. The CPU may believe data is in the cache when in fact it isn't, leading to incorrect data being loaded, which an attacker could then infer.
TSA-SQ vulnerabilities arise when a load instruction erroneously retrieves data from the store queue when the required data isn't available. In this case, the incorrect data can be detected by an attacker and used to infer data, such as that from the OS kernel, from previously loaded stores, even if they were executed in a different context.
Patch galore
The number of chip series affected by the TSAs is fairly extensive, affecting both consumer and enterprise-grade systems.
[14]Microsoft enjoys first Patch Tuesday of 2025 with no active exploits
[15]Samsung predicts profit slump as its HBM3e apparently continues to underwhelm Nvidia
[16]With OpenAI, there are no allegiances - just compute at all costs
[17]China claims breakthroughs in classical and quantum computers
The full list can be viewed via AMD's [18]advisory but at a high level, [19]EPYC , [20]Ryzen , [21]Instinct , and Athlon-series chips should be updated.
Sysadmins should update to the latest Windows builds to protect against these TSAs, AMD advised. There is a mitigation that involves a VERW instruction, but AMD says this may impact system performance, so deciding which remediation route to take will require a risk-reward assessment from each admin.
The good news is that not only are these kinds of attacks difficult to pull off, typically reserved only for the most well-resourced groups, but there is no known exploit code available anywhere, according to Microsoft. ®
Get our [22]Tech Resources
[1] https://www.theregister.com/2018/01/04/intel_amd_arm_cpu_vulnerability/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aG7mdufv4Vt4M14MboN07AAAAEk&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aG7mdufv4Vt4M14MboN07AAAAEk&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aG7mdufv4Vt4M14MboN07AAAAEk&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7029.html
[6] https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2025-36350
[7] https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2025-36357
[8] https://www.cve.org/CVERecord?id=CVE-2025-36348
[9] https://www.cve.org/CVERecord?id=CVE-2025-36349
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aG7mdufv4Vt4M14MboN07AAAAEk&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[11] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aG7mdufv4Vt4M14MboN07AAAAEk&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[12] https://www.amd.com/content/dam/amd/en/documents/resources/bulletin/technical-guidance-for-mitigating-transient-scheduler-attacks.pdf
[13] https://www.amd.com/content/dam/amd/en/documents/resources/bulletin/technical-guidance-for-mitigating-transient-scheduler-attacks.pdf
[14] https://www.theregister.com/2025/07/08/microsoft_patch_tuesday/
[15] https://www.theregister.com/2025/07/08/samsung_q2_2025_guidance/
[16] https://www.theregister.com/2025/07/01/openai_google_tpu/
[17] https://www.theregister.com/2025/06/30/china_claims_breakthroughs_in_classical/
[18] https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7029.html
[19] https://www.theregister.com/2025/05/13/amd_epyc_4005/
[20] https://www.theregister.com/2024/11/07/amd_ryzen_9800x3d_review/
[21] https://www.theregister.com/2024/12/23/nvidia_ai_hardware_competition/
[22] https://whitepapers.theregister.com/
Surely it is 1A: nobody ever tried, as this is a new public release of information about specific techniques. Whether Apple (or Intel, or any other CPU manufacturer) will try it on their own hardware is up to them. 3rd party security researchers may do so as well. In cases like this it is definitely not as simple as 'compile and test'; one must thoroughly understand the target CPU design in order to create attacks based on the same concept, but targeted to the actual facilities at hand.
only?
"AMD said it could only be carried out by an attacker able to run arbitrary code on a target machine."
So, bad news for any cloud providers out there then, whose line of business is literally letting third parties run arbitrary code on their machines.
Re: only?
Well, most of the cpu issues found recently are mostly problematic for cloud operators and even then only if you share the servers between clients (which is often).
As for running random stuff on the desktop, yeah, that happens all the time (one has to install stuff to work or play or wtv).
These days as long i'm not part of a botnet I don't know what is the difference between having my data at third parties because i use google/apple/ms services or bad operators...
From all I read, this is a class of bugs that could happen on an Apple Mx chip as well, but I never saw this mentioned. What is the reason?
0. Doesn’t happen on M1-M4
1. Nobody ever tried.
2 Apple doesn’t care.
3. Apple has the same costly workarounds but doesn’t tell anyone.
4. By design or luck the workarounds are cheaper, say 4% instead of 20%.
5. The OS runs critical software on one fully protected core, or one an efficiency core, and as long as you use the OS code you are safe.
I’d bet on 0. or more likely 5., especially since the low power cores should be safe, and you should be able to use up to six of them.