StackWarp: The AMD Zen Vulnerability Rewriting Confidential VM Security

The fundamental promise of confidential computing—that sensitive workloads can run securely even on untrusted cloud infrastructure—faces a profound challenge with the discovery of StackWarp, a vulnerability present in all AMD Zen 1–5 processors. This hardware-level flaw fundamentally undermines AMD's Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP), enabling malicious hypervisors to manipulate a guest VM's stack pointer with surgical precision. The consequences are severe: attackers can bypass authentication mechanisms, escalate privileges, and extract cryptographic keys from supposedly isolated environments.

Core Vulnerability: The Stack Engine's Silent Failure

At the heart of StackWarp lies a synchronization failure in AMD's stack engine, an optimization mechanism designed to accelerate stack operations. Modern CPUs track stack pointers through two pathways: the architectural register (visible to software) and a speculative delta maintained in the frontend for performance. Normally, these states synchronize seamlessly. However, researchers discovered that bit 19 of an undocumented core-scoped Model-Specific Register (MSR 0xC0011029) controls the stack engine's activation—and crucially, this setting isn't synchronized between sibling hyperthreads.

MSR toggling across SMT threads enables deterministic stack corruption

By rapidly toggling this bit from a sibling hyperthread, an attacker induces a "freeze-release" effect:

1. Freeze Phase: Disabling the stack engine causes stack operations (push/pop/call/ret) to execute memory updates while withholding the architectural stack pointer adjustment
2. Release Phase: Re-enabling the engine applies the accumulated delta in one atomic step

This allows a malicious hypervisor to inject arbitrary offsets into a guest's stack pointer without reading encrypted memory—a fatal violation of SEV-SNP's security guarantees.

Exploit Scenarios: From SSH Bypass to Root Escalation

Researchers demonstrated StackWarp's potency through two proof-of-concept attacks targeting Linux environments:

1. OpenSSH Password Authentication Bypass

• During password verification, StackWarp shifts the stack pointer by 32 bytes before shadow_pw() returns
• The corrupted stack causes the function to bypass normal execution flow
• sys_auth_passwd() incorrectly interprets the return value as authentication success
• Result: Remote root login without valid credentials

2. Privilege Escalation via getuid Manipulation

• A two-stage attack during getuid system call execution:
  • First offset (-8 bytes) corrupts the pop rax instruction to load 0 (root UID) instead of the real UID
  • Second offset (+8 bytes) restores stack alignment to avoid detection
• sudo accepts the forged root UID and grants unrestricted access
• Result: Unprivileged user obtains root shell

Additional demonstrations showed RSA key extraction via single faulty signatures and kernel ROP chain execution, confirming StackWarp's versatility as both control-flow and data-flow attack primitive.

SEV-SNP: The Broken Foundation

AMD's SEV-SNP architecture promised hardware-enforced VM integrity by encrypting memory and registers while preventing hypervisor tampering through mechanisms like memory tagging and attestation. StackWarp circumvents these protections entirely by manipulating CPU-internal state invisible to memory encryption. The vulnerability transforms what should be hardware-enforced isolation into software-reliant security—a distinction with devastating consequences for confidential computing adopters.

Discovery Methodology

The research team uncovered StackWarp through systematic fuzzing of undocumented MSRs across Zen microarchitectures. By pinning victim processes (SEV-SNP guests) to one hyperthread while rapidly toggling MSR bits from the sibling thread, they observed consistent architectural deviations:

• Segmentation faults triggered by misaligned stacks
• Return address corruption during stack-intensive operations
• Deterministic control of stack pointer deltas

Through reverse engineering, they correlated these anomalies to the stack engine's synchronization flaw, demonstrating how privileged MSR writes (possible only for hypervisors) become a vector for guest compromise.

Mitigation Landscape

AMD has released hot-loadable microcode patches addressing CVE-2025-29943. Until patched, organizations should:

1. Disable Simultaneous Multithreading (SMT) on AMD hosts running SEV-SNP workloads
2. Avoid deploying sensitive workloads on unpatched Zen 1–5 systems
3. Monitor AMD's security advisories for vendor-specific guidance

The vulnerability does not affect traditional VM isolation models or systems without SEV-SNP enabled.

Technical FAQ

Q: Is this a side-channel attack? A: No. StackWarp causes deterministic architectural corruption, not probabilistic leakage.

Q: Does StackWarp require physical access? A: No. Malicious cloud providers or compromised hypervisors can exploit it remotely.

Q: Are non-SEV-SNP systems vulnerable? A: The hardware bug exists in all Zen CPUs, but without SEV-SNP, attackers lack the privileged MSR access required for exploitation.

Q: Where can I find technical details? A: The full paper will appear in USENIX Security 2026 proceedings. Current mitigation guidance is in AMD's security bulletin.

Acknowledgements

Discovered by Ruiyi Zhang, Tristan Hornetz, Daniel Weber, Fabian Thomas, and Michael Schwarz (CISPA Helmholtz Center for Information Security). Funded in part by the Semiconductor Research Corporation's Hardware Security Program.

---

Logo usage: The StackWarp logo () may be used with attribution to the research team for educational and reporting purposes.