As reported by The Hacker News, Google Cloud has disclosed that three AMD Turin (Zen 5) processor side-channel vulnerabilities—collectively classified as Transient Scheduler Attacks (TSA)—affect multiple Google Cloud machine series and require coordinated guest OS patching plus a VM stop-and-start cycle to fully mitigate.
While Google has already addressed inter-VM and VM-to-host attack vectors at the hypervisor layer, the residual risk lives inside the guest: an attacker with code executing on the same physical core may infer data from other processes or the kernel within that VM. This is a nuanced but important distinction that shapes how defenders should prioritize remediation.
Vulnerability Summary
| CVE | Name | Description | Scope |
|---|---|---|---|
| CVE-2024-36350 | TSA-SQ | Scheduler queue transient execution leak | Local, high complexity |
| CVE-2024-36357 | TSA-L1 | L1 data cache inference via transient scheduling | Local, high complexity |
| CVE-2026-0004 | TSA-Fill | L1 data cache fill logic inference (new) | Local, high complexity |
Severity: Medium (Google); High attack complexity, low privileges required (AMD)
Vendor: AMD (EPYC Turin / Zen 5)
Affected Google Cloud Series: C4D, N4D, H4D, Z4D, G4 (including bare-metal C4D and Z4D)
Patch Status: Guest OS vendor fixes pending; Google CPU info updates rolling out this week
Active Exploitation: None reported; not in CISA KEV catalog
Why This Matters
This disclosure is the latest chapter in a multi-year pattern of speculative execution side-channel research that has progressively eroded the assumption that software-level isolation is sufficient on shared silicon. The TSA family specifically targets the CPU scheduler's transient execution behavior—the brief window where out-of-order execution touches data that should be architecturally inaccessible.
What makes this episode particularly notable is AMD's correction of its prior position. The Xen Project notes that AMD had previously stated Zen 5 CPUs were not vulnerable to TSA-SQ and TSA-L1. That assertion has now been walked back, with AMD clarifying that Zen 5 is "impacted differently" from earlier EPYC generations. For defenders who relied on that earlier assurance to defer patching on Turin-based infrastructure, this correction should trigger immediate reassessment.
The stop-and-start requirement—explicitly stated by Google as not equivalent to a guest OS reboot—reflects the depth at which these mitigations must be applied. A reboot preserves CPU context state; a stop-and-start forces a fresh CPU assignment, ensuring the updated CPU information is surfaced to the patched guest kernel so it can enable its own protections.
Who Is Most Exposed
- Multi-tenant workloads with untrusted code: Organizations running containers, serverless functions, or CI/CD pipelines where multiple tenants or projects share a physical core face the highest intra-VM inference risk.
- Bare-metal instance operators: C4D and Z4D bare-metal customers bear full responsibility for applying OS and hypervisor vendor fixes—Google's hypervisor-level mitigations do not apply there.
- Sensitive data co-located with general compute: Environments where cryptographic operations, secrets, or regulated data share a core with less-trusted workloads face elevated confidentiality risk even without exploitation.
- Latency-sensitive workloads: The stop-and-start requirement introduces operational disruption. VMs with long-lived connections, in-memory state, or strict SLAs need migration planning before remediation windows.
Shield53 Recommendations
Immediate Actions:
- Inventory exposure: Identify all VMs and bare-metal instances running on C4D, N4D, H4D, Z4D, or G4 series. Tag them for tracking through the remediation cycle.
- Monitor for guest OS patches: Engage your OS vendor (Ubuntu, RHEL, SUSE, etc.) for the TSA mitigation patches. Subscribe to their security mailing lists if you haven't already.
- Plan stop-and-start windows: Unlike a reboot, stop-and-start drops in-memory state. Use instance groups, migration strategies, or blue-green deployments to avoid downtime for stateful workloads.
- Prioritize bare-metal remediation: C4D and Z4D bare-metal operators have no hypervisor safety net. Apply vendor fixes as soon as they ship and validate that mitigations are active at boot.
- Validate mitigation status post-action: After stop-and-start, confirm the guest kernel recognizes updated CPU information and has enabled TSA mitigations. Use vendor-provided tooling or
cat /proc/cpuinfoflags to verify. - Reduce cross-tenant core sharing where feasible: For workloads with strict confidentiality requirements, consider sole-tenant nodes or dedicated core configurations to eliminate the intra-VM inference attack surface.
Broader Consideration: The pattern of CPU vendors initially asserting immunity, then correcting course, underscores that microarchitectural security is a moving target. Organizations operating at cloud scale should treat side-channel mitigations as a continuous operational discipline—not a one-time patch. Assume that any generation of CPU may eventually be found vulnerable, and architect accordingly: isolate sensitive workloads, minimize secret residency in shared-core environments, and maintain the operational muscle to execute coordinated restarts at fleet scale.
