AMD Zen 5 Turin Transient Scheduler Attacks (CVE-2026-0004): Why Rebooting Cloud VMs Is Not Enough

Executive Summary

On November 10–13, 2026, AMD and Google Cloud issued coordinated guidance addressing three Transient Scheduler Attack (TSA) side-channel vulnerabilities affecting 5th Generation AMD EPYC ("Turin") and broader AMD Zen 5 processors: CVE-2024-36350 (TSA-SQ), CVE-2024-36357 (TSA-L1), and a newly disclosed Zen 5 variant, CVE-2026-0004 (referred to by the Xen Project as TSA-Fill).

The disclosure reverses an earlier architectural assumption. As documented by The Hacker News and BastionZero, AMD had previously characterized Zen 5 CPUs as unaffected by TSA-SQ and TSA-L1. In its November 10, 2026 bulletin (AMD-SB-7073), AMD revised that assessment, stating that Zen 5 processors are "impacted differently from previously characterized AMD processors."

For cloud operators and bare-metal infrastructure teams, three operational facts govern remediation:

1. Cross-VM Host Isolation vs. Intra-VM Exposure: Google Cloud confirmed it has already deployed host-level mitigations blocking cross-VM and VM-to-host leakage on affected Turin machine series (C4D, N4D, H4D, Z4D, and G4, including bare-metal C4D and Z4D). However, intra-VM exposure (an unprivileged local process inferring kernel or co-resident process data on the same core) remains the customer's responsibility.
2. A Guest OS Reboot Is Insufficient: Google Cloud explicitly warns that "Rebooting the guest OS isn't enough." Once Google updates the virtualized CPUID/CPU information exposed to a VM, administrators must install the guest OS kernel patch and execute a full stop and start of the VM instance so the guest kernel can detect the updated CPU flags and activate mitigations.
3. Dual-Layer Requirement on Owned Hardware: Organizations running self-hosted Zen 5 EPYC (8005, 9005, 4005 series) or Ryzen 9000/Threadripper PRO 9000 WX-series hardware require both Platform Initialization (PI) firmware/microcode updates and OS kernel patches, while weighing potential workload performance impacts.

---

Hardware Scope and Cloud Affected Matrix

AMD's AMD-SB-7073 bulletin covers the full Zen 5 silicon portfolio across server, embedded, desktop, and workstation lines.

---

Technical Mechanics: How Transient Scheduler Attacks Work on Zen 5

Transient Scheduler Attacks exploit speculative execution timing windows and shared microarchitectural buffers inside a single physical core. Unlike network-reachable software bugs, AMD classifies CVE-2024-36350 and CVE-2024-36357 (CVSS v3.1 5.6, AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N, CWE-421) and CVE-2026-0004 as local attacks requiring low privileges and high attack complexity.

+-----------------------------------------------------------------------------+
|             ZEN 5 TRANSIENT SCHEDULER ATTACKS (TSA) & MITIGATION            |
+-----------------------------------------------------------------------------+
|                                                                             |
|  [ INTRA-VM ATTACK SURFACE (SHARED CORE) ]                                  |
|   Unprivileged Guest Process                                                |
|     |-- TSA-SQ  (CVE-2024-36350) ---> Infers data from prior Store Queue    |
|     |-- TSA-L1  (CVE-2024-36357) ---> Microtag alias reads L1D cache        |
|     +-- TSA-Fill (CVE-2026-0004) ---> Infers data in L1D cache on Zen 5     |
|                                                                             |
|  [ DEFENSIVE HARDWARE + KERNEL BOUNDARY ]                                   |
|   1. Microcode / PI Firmware (linux-firmware >= Sep 23, 2026)               |
|      +---> Exposes CPUID mitigation bits (VERW_CLEAR / TSA_*_NO)            |
|   2. Hypervisor / Cloud Control Plane                                       |
|      +---> Requires VM STOP & START (not soft reboot) to reload CPUID       |
|   3. Guest Linux Kernel                                                     |
|      +---> Issues VERW buffer-clearing on privilege/context transitions     |
+-----------------------------------------------------------------------------+

1. Store Queue Leakage (CVE-2024-36350 / TSA-SQ)

Under specific scheduling conditions, a load instruction can transiently observe stale data from previous store queue entries, allowing an unprivileged user-space process to infer privileged kernel data on the same core.

2. L1 Data Cache Microtag Aliasing (CVE-2024-36357 / TSA-L1)

Modern AMD processors use a linear-address-based microtag to accelerate L1 data-cache (L1D) lookups. As detailed in AMD's Technical Guidance for Mitigating Transient Scheduler Attacks, if a load hits a matching microtag entry even when the L1D does not hold the target data, a false completion can transiently expose data from the aliased L1D line across privilege boundaries (kernel-to-user, user-to-user, or guest-to-guest). Note that the microtag structure is not shared between Simultaneous Multithreading (SMT) sibling threads.

3. Zen 5 L1D Cache Fill Variant (CVE-2026-0004 / TSA-Fill)

Disclosed alongside the Zen 5 update in November 2026, CVE-2026-0004 (termed TSA-Fill by the Xen Project) allows an attacker executing local code on a Zen 5 core to infer data held in the L1 data cache.

4. Why Soft Reboots Fail in Cloud VMs

Virtual machines cache their virtualized CPUID feature flags at instance boot from the underlying hypervisor's machine definition. When Google Cloud rolls out the host-side CPU information update to Turin hosts, a soft sudo reboot inside the guest OS restarts the guest kernel within the same QEMU/hypervisor process—meaning the guest still sees the old CPUID flags and fails to enable its TSA kernel mitigations. Only a full Stop and Start deallocates and reallocates the VM's hypervisor instance with the updated CPUID bits.

---

Evidence: Exploitation Status, Distribution Patch Gaps, and SEV-SNP

Exploitation and Severity Assessment

• Zero Known Exploitation: As of November 13, 2026, neither AMD, Google Cloud, nor CISA reports active exploitation in the wild, and none of the three CVEs appear in the CISA Known Exploited Vulnerabilities (KEV) catalog.
• Severity: Google Cloud rates the issue Medium; AMD scores CVE-2024-36350 and CVE-2024-36357 at 5.6 (CVSS v3.1), noting that specific scores vary by implementation.

Uneven Linux Distribution Coverage

While the upstream Linux kernel source tree and the Xen Project have published patches—and the Xen Project notes that microcode covering all TSA flaws on Zen 5 has been present in linux-firmware since September 23, 2026—downstream Linux distribution packaging remains uneven as of November 13, 2026:

• Debian: According to The Hacker News and BastionZero, Debian has patched CVE-2026-0004 only in its unstable branch, leaving kernels in bookworm, trixie, and forky marked vulnerable on Debian's security tracker.
• GKE Bare Metal: Updated GKE node images for Turin-based bare-metal instances are planned but not yet listed as published in Google's bulletin.
• Unanswered Telemetry Gap: Google Cloud's bulletin does not currently provide a self-service API flag or metadata endpoint confirming whether the host CPU information update has reached a specific running VM prior to stop/start.

AMD SEV-SNP Confidential Computing Impact

AMD's TSA Technical Guidance notes that TSA could allow a malicious hypervisor to infer data inside an AMD SEV-SNP guest unless the host has loaded the required microcode and SEV-SNP firmware (1.3A.05 for EPYC 9005, updating the SNP TCB to [SNP]=0x6). Guest owners must verify host microcode compliance through SEV-SNP attestation reports, as affected SEV-SNP firmware blocks hypervisors from falsely asserting TSA_L1_NO, TSA_SQ_NO, or TSA_FILL_NO CPUID bits.

---

Hardening Playbook: Inventory, Kernel Verification, and VM Lifecycle

Execute the following steps across Google Cloud Turin VMs and self-hosted Zen 5 servers.

Step 1: Inventory Affected Google Cloud Turin Instances

Use gcloud to locate all running VMs in affected machine families (c4d, n4d, h4d, z4d, g4) across your projects:

    # List all Compute Engine instances running on AMD Turin machine families
gcloud compute instances list \
  --filter="machineType~'(c4d|n4d|h4d|z4d|g4)-'" \
  --format="table(name,zone,machineType.basename(),status)"

Step 2: Check Guest Kernel Vulnerability and Mitigation Status

Inspect the Linux sysfs CPU vulnerability interface inside each guest or bare-metal host to see whether TSA mitigations are active:

    # Inspect CPU vulnerability status on Linux hosts/guests
grep -H . /sys/devices/system/cpu/vulnerabilities/*

    # Check specifically for TSA and CPU model / microcode revision
lscpu | grep -E "Model name|Vendor ID|Stepping"
grep -m1 microcode /proc/cpuinfo
cat /sys/devices/system/cpu/vulnerabilities/tsa 2>/dev/null || echo "tsa sysfs entry not present in current kernel"

Step 3: Patch Guest OS Kernel and linux-firmware

Apply your Linux distribution's latest security kernel and linux-firmware packages (ensuring linux-firmware is at least the September 23, 2026 or newer build on bare-metal/self-hosted systems):

    # Example Ubuntu/Debian check for installed kernel and linux-firmware
dpkg -l | grep -E "linux-image|linux-firmware"

    # Example RHEL/Rocky/Alma update command
sudo dnf update kernel linux-firmware -y

Step 4: Execute a Full VM Stop and Start (Not Soft Reboot)

For Google Cloud C4D, N4D, H4D, Z4D, and G4 VMs, after patching the guest OS, perform a stop and start cycle to pick up Google's updated CPUID flags:

    # Full stop and start (required to reload hypervisor CPU information)
gcloud compute instances stop INSTANCE_NAME --zone=ZONE
gcloud compute instances start INSTANCE_NAME --zone=ZONE

Re-run cat /sys/devices/system/cpu/vulnerabilities/tsa after the instance starts to confirm the mitigation is active (Mitigation: Clear CPU buffers or equivalent kernel status).

Step 5: Self-Hosted Hardware BIOS/PI Firmware & SEV-SNP Attestation

For on-premises or bare-metal AMD EPYC 9005/8005/4005 or Ryzen 9000 systems:

1. Obtain the OEM BIOS update incorporating AMD Platform Initialization (PI) firmware (TurinPI_1.0.0.B or later for EPYC 9005/8005; ComboAM5PI 1.3.0.1d for EPYC 4005/Ryzen 9000).
2. For AMD SEV-SNP confidential VMs on EPYC 9005, verify SEV firmware 1.3A.05 is active and enforce attestation policy checks requiring [SNP]=0x6 before releasing sensitive keys to guests.

Step 6: Benchmark Workload Performance & Rollback Notes

AMD explicitly advises that TSA mitigations (which insert VERW buffer-clearing instructions on context boundaries) may affect workload performance. Benchmark latency-sensitive databases, HFT/trading engines, or high-IOPS services in staging before rolling out fleet-wide.

• Rollback: If a specific non-multi-tenant, single-trust-domain workload experiences unacceptable latency regression on self-hosted hardware, Linux kernels expose tsa=off (or mitigations=off, though not recommended on multi-tenant hosts) as a boot parameter—only consider this if all processes inside the VM/host belong to the same trust boundary.

---

Frequently Asked Questions

1. Why is a standard Linux reboot not enough for Google Cloud AMD Turin VMs?

A soft OS reboot restarts the kernel inside the existing virtual machine process without tearing down the underlying hypervisor context. To receive Google Cloud's updated virtual CPUID flags—which tell a patched guest kernel to enable TSA mitigations—you must fully stop and then start the VM.

2. Which Google Cloud machine series are affected by these AMD Turin CPU flaws?

The advisory covers C4D, N4D, H4D, Z4D, and G4 machine series, including C4D and Z4D bare-metal instances. Google Cloud Run requires no customer action.

3. Are cross-VM or VM-to-host attacks still possible on Google Cloud?

Google Cloud states it has already applied infrastructure-level mitigations to block cross-VM and VM-to-host attacks. The remaining exposure is intra-VM: an attacker who already has low-privileged code execution inside your VM attempting to infer data from other processes or the guest kernel on the same core.

4. What is CVE-2026-0004 (TSA-Fill), and how does it differ from TSA-SQ and TSA-L1?

CVE-2024-36350 (TSA-SQ) leaks data from prior store queue entries, and CVE-2024-36357 (TSA-L1) exploits L1D microtag aliasing. CVE-2026-0004 (termed TSA-Fill by the Xen Project) is a newly disclosed Zen 5 variant that allows local code execution to infer data in the processor's L1 data cache.

5. Are these three AMD Zen 5 vulnerabilities being actively exploited?

No. As of November 13, 2026, neither AMD, Google Cloud, nor CISA reports any exploitation in the wild, and none of the three CVEs are listed in the CISA KEV catalog.

---

Sources

• AMD Product Security Bulletin: AMD Transient Scheduler Attacks for "Zen 5" Processors (AMD-SB-7073) — Initial version published November 10, 2026.
• AMD Technical Guidance for Mitigating Transient Scheduler Attacks (PDF) — Official microarchitectural and SEV-SNP mitigation specification.
• The Hacker News: Google Cloud Warns Three AMD Turin CPU Flaws Could Leak Data Across Processes in VMs — Published November 12, 2026.
• BastionZero: Google Cloud Tells AMD Turin VM Users to Patch and Restart — Published November 13, 2026.
• SC World: Google Cloud addresses transient scheduler attacks on AMD Turin processors — Published November 13, 2026.