Flipping one bit leaves AMD CPUs open to VM vuln

Steven

Flipping one bit leaves AMD CPUs open to VM vuln

Summary

Researchers at CISPA have disclosed “StackWarp”, a microarchitectural vulnerability (CVE-2025-29943) that lets a host-controlled attacker manipulate a protected AMD SEV-SNP guest by flipping a single undocumented control bit. The flaw abuses the CPU frontend’s stack engine (by toggling bit 19 of MSR 0xC0011029) while Simultaneous Multithreading (SMT) is enabled, breaking synchronization between sibling threads and letting an attacker change a guest’s stack pointer with instruction-level precision. The attack can recover RSA keys, bypass OpenSSH and sudo password checks, and achieve ring 0 code execution. AMD released fixes in July 2025 and a security bulletin; OEM firmware updates and operator actions are required. Proof-of-concept code is public on GitHub.

Key Points

  • StackWarp (CVE-2025-29943) targets AMD Zen CPUs’ stack engine via an undocumented MSR bit (bit 19 of 0xC0011029).
  • Vulnerability affects AMD SEV-SNP guests when SMT (hyperthreading) is enabled, allowing a sibling thread to manipulate the guest’s stack pointer.
  • Successful exploitation can recover RSA-2048 private keys, bypass OpenSSH and sudo authentication, and modify kernel stacks to obtain ring 0 execution.
  • AMD issued patches in July 2025 and rates the issue as low severity, but OEM firmware updates and operator configuration changes may still be necessary.
  • Proof-of-concept exploit code has been published by the researchers; operators should apply vendor updates or consider disabling SMT where appropriate.

Content summary

The paper and disclosures from CISPA detail how the CPU frontend’s stack engine optimises stack-pointer tracking by maintaining a running delta. If the engine is disabled mid-flight, the accumulated delta can be frozen so stores commit while the architectural stack pointer update is withheld. By flipping a previously undocumented control bit on the hypervisor side, an attacker on a sibling hyperthread can desynchronise stack handling and corrupt a protected guest’s control and data flow.

The researchers demonstrate practical impacts: extraction of cryptographic keys, authentication bypasses, and privilege escalation to kernel-level code. The attack is applicable to SEV-SNP (the stronger successor to SEV and SEV-ES) on Zen CPUs with SMT active. CISPA published a full paper and proof-of-concept on GitHub, and AMD released mitigations in mid-2025; operators must follow up with OEM firmware updates and configuration changes.

Context and relevance

Confidential VMs (CVMs) such as AMD SEV-SNP and Intel TDX are core to cloud confidential computing offerings. StackWarp is another reminder that microarchitectural features intended to speed CPUs (like stack engines and SMT) can introduce isolation risks. Cloud providers, enterprise operators and security teams running customer or multi-tenant workloads must treat this as an operational priority: patches need to be applied, OEM firmware tracked, and mitigation options (patching, disabling SMT, or other hardening) evaluated. The publication also continues a trend of hardware-level research showing that CPU optimisations frequently create exploitable channels.

Author style

Punchy: this is not academic fluff. If you run or host VMs on AMD hardware, StackWarp could let a co-located sibling thread undo the whole point of confidential VMs. AMD patched in July 2025 but OEM firmware and operator action remain important — so get your updates lined up.

Why should I read this?

Short answer: because one bit flip can wreck VM isolation. If you manage cloud instances, confidential VMs, or run multi-tenant hosts on AMD Zen silicon, this directly affects your threat model. We’ve read the paper and pulled out the actions: check AMD patches, chase OEM firmware updates, and consider turning off SMT where you can—so you don’t have to dig through the microarchitecture paper yourself.

Source

Source: https://www.theregister.com/2026/01/15/stackwarp_bug_amd_cpus/