StackWarp

StackWarp is a security vulnerability that exploits a synchronization bug present in all AMD Zen 1–5 processors. In the context of SEV-SNP, this flaw allows malicious VM hosts to manipulate the guest VM’s stack pointer. This enables hijacking of both control and data flow, allowing an attacker to achieve remote code execution and privilege escalation inside a confidential VM.

Demo

We demonstrate StackWarp’s security impact with two proof-of-concept exploits:

For the first exploit, we target the password check in OpenSSH to log into the machine without providing a password. When a user provides a password, sys_auth_passwd() calls shadow_pw() to retrieve the stored hash.

Using StackWarp, we shift the stack pointer by 32 bytes just before shadow_pw() returns. This stack corruption causes the function shadow_pw() to not take its normal return path, but instead return directly to the caller of sys_auth_passwd(). Because shadow_pw() returns a non-zero value, the caller interprets this as a non-zero value stemming from sys_auth_passwd(), i.e., a successful password match, and grants access.

The second exploit demonstrates how StackWarp enables manipulation of the getuid system call’s data flow, allowing an unprivileged user to obtain a root shell in SEV-SNP confidential VMs.

When a user runs sudo, sudo calls getuid to check if the current UID is already 0 (root), and if so, skips further access checks and grants root permissions. To manipulate getuid, we perform a two-shot stack pointer manipulation within the Linux kernel’s system call handler.

Just before the kernel restores the userspace registers, we inject an offset of -8 bytes. This modification tricks the pop rax instruction, which should load the user’s real UID, to load 0 instead. Immediately after, we mount StackWarp again and inject an offset of +8 bytes, restoring the stack to its original state and allowing the normal control flow to continue. Since the return value of getuid, stored in rax and corrupted to 0, represents the UID of root, sudo successfully elevates the user’s privileges to root.

Fundamentals.

Stack Engine.

In modern computing, the stack is a memory structure used by every program to manage function calls, local variables, and return addresses. The top of the stack is tracked using a dedicated CPU register called the stack pointer. Every time a function is called, or a variable is stored on the stack, the CPU executes instructions like push, pop, call, or ret to adjust the stack pointer.

As the CPU frontend, responsible for fetching instructions, frequently requires the stack pointer’s position, but the CPU backend is responsible for updating the stack pointer, a naïve CPU frontend implementation would always require the CPU frontend to query stack pointer updates from the CPU backend. To gain performance and optimize this behavior, Intel and AMD CPUs add a so-called stack engine to the CPU frontend. The stack engine tracks stack pointer updates in the CPU frontend and reduces synchronization between the CPU frontend and backend.

The stack engine does so by tracking a hidden, speculative running delta of all stack pointer changes. This allows the CPU to execute stack operations with zero apparent latency. Periodically, the CPU merges this delta back into the actual architectural register to ensure the program’s state remains accurate.

SEV-SNP.

Confidential Virtual Machines.

AMD Secure Encrypted Virtualization (SEV) is a CPU extension enabling a more secure separation between virtual machines (VMs) and the underlying hypervisor. AMD SEV allows developers to deploy VMs in an untrusted hypervisor environment securely. In other words, this means that computations in the cloud can be performed on confidential data even if the cloud provider is untrusted or compromised.

AMD SEV achieves this level of protection by encrypting the VM’s data. The encryption applies to the VM’s memory as well as its register state upon context switches. The latest and most secure variant of SEV, namely, AMD SEV-SNP, additionally prevents cloud providers from altering the data stored inside the VM.

StackWarp.

Deterministically Controlling the Stack Pointer.

StackWarp is a software-based architectural attack targeting AMD SEV-SNP confidential virtual machines (CVMs). It exploits a synchronization failure in the stack engine that manages stack pointer updates in the CPU frontend. The vulnerability exists because bit 19 of the undocumented core-scoped model-specific register (MSR) 0xC0011029 can enable or disable the stack engine and is not properly synchronized between logical sibling cores. While the underlying bug is present across Zen 1–5 microarchitectures, it only becomes a security issue in the context of AMD SEV as MSR writes require a privileged attacker.

By toggling bit 19 of MSR 0xC0011029 from a sibling hyperthread, an attacker induces a “freeze-release” effect. While the engine is disabled, stack instructions like push or pop commit their memory updates, but the architectural update to the stack pointer is withheld and “frozen”. Re-enabling the engine later, by toggling the bit again, releases this accumulated delta in one step. Thus, allowing a malicious hypervisor to inject a deterministic attacker-chosen offset into a guest’s stack pointer without reading encrypted memory.

This allows an attacker to redirect control flow or manipulate data flow. We demonstrate that through these primitives, an attacker can recover RSA private keys from a single faulty signature, bypass OpenSSH password authentication, or escalate privileges by either bypassing sudo authentication or using a kernel ROP chain.

To mitigate the issue, AMD has released hot-loadable microcode patches. Also, disabling SMT is an effective immediate stopgap.

One Core, Two Threads:

The Discovery of StackWarp.

The discovery of StackWarp began with a systematic exploration of undocumented MSRs on AMD Zen CPUs. We specifically investigated the behavior of core-scoped MSRs, which are shared between the two logical threads belonging to the same physical core.

Our experimental setup involved a synchronized sibling attack: we ran a host agent on one logical core while pinning a victim process, an SEV-SNP guest, to the sibling logical core. The host agent rapidly toggled undocumented MSR bits to see if the state change on one thread would silently affect the execution state on the other.

We discovered that flipping a specific bit in MSR 0xC0011029 (bit 19) consistently caused the victim process on the sibling thread to experience architectural deviations. Specifically, we observed segmentation faults and corrupted return addresses in the guest VM, indicating that the stack pointer was being modified without any direct instruction from the guest itself. By correlating these crashes with stack-intensive code, we pinpointed the issue to a synchronization failure in the CPU’s stack engine.

For more details on the discovery process and our findings, we refer to our research paper, which will be published in the proceedings of USENIX Security 2026.

Who found it?

FAQ

Am I affected by this vulnerability?

If you have an AMD CPU supporting AMD SEV, yes, your machine is affected. Nevertheless, if you do not rely on deploying confidential virtual machines (CVMs) using AMD SEV, this vulnerability cannot be leveraged by an attacker. For more details, please refer to the official AMD Security Bulletin.

What is AMD SEV?

AMD Secure Encrypted Virtualization (SEV) is a CPU extension enabling secure virtual machines in the presence of an untrusted or compromised hypervisor.

Does StackWarp affect traditional virtual machine isolation?

No, StackWarp only affects AMD SEV, as traditional virtual machines do not offer any protection against malicious hypervisors.

Is this a software or a hardware bug?

StackWarp is a hardware bug in AMD CPUs.

Is this a side-channel or transient-execution attack?

No, StackWarp is an architectural bug and not a transient-execution attack like Meltdown or Spectre. It is also not a side-channel attack.

Is there any evidence of this vulnerability being exploited in the wild?

As of now, we have no evidence of any instances in the wild where this vulnerability has been exploited.

Is there more technical information about StackWarp?

Yes, there is an academic research paper, which will be published at USENIX Security 2026.

What is CVE-2025-29943?

CVE-2025-29943 is the official reference to StackWarp. CVE is the standard for naming information security vulnerabilities maintained by MITRE.

Can I use the logo?

The logo is free to use, rights waived via CC0. Logo designed by Chiara Schwarz.

Logo	Preview	File
Text dark		stackwarp-text-dark.svg
Text light		stackwarp-text-light.svg
No text dark		stackwarp-no-text-dark.svg
No text light		stackwarp-no-text-light.svg
Horizontal dark		stackwarp-horizontal-dark.svg
Horizontal light		stackwarp-horizontal-light.svg
Vertical dark		stackwarp-vertical-dark.svg
Vertical light		stackwarp-vertical-light.svg

Acknowledgements

We want to thank our shepherd and the anonymous reviewers for their guidance, comments, and valuable suggestions, as well as Lukas Gerlach and Youheng Lü for helpful feedback on this work. This work was partly supported by the Semiconductor Research Corporation (SRC) Hardware Security Program (HWS). Any opinions, findings, conclusions, or recommendations expressed in this work are those of the authors and do not necessarily reflect the views of the funding parties.