StackWarp (CVE-2025-29943): Exploiting an AMD SEV Hypervisor Vulnerability with a Data-Only Attack

On January 16, 2026, researchers at the CISPA Helmholtz Center for Information Security published StackWarp (CVE-2025-29943), a new CPU vulnerability that allows a malicious hypervisor to compromise encrypted virtual machines protected by AMD SEV.

This post tells the story of how I quickly identified promising research and helped turn a new exploit primitive into a working data-only exploit within two hours. The work reflects the flexibility we have at SCHUTZWERK — I was able to quickly reallocate some of my time to pursue a highly promising research project.

I’ll start with the story, then provide a technical overview of the sudo data-only exploit described in Section 6.3 of the paper.

The Story

It all started with an innocent-looking message:

August 16, 2025 Ruiyi Zhang – 4:12 PM “Youheng, do you still recall which function of sudo you examined for CacheWarp?”

For context, Ruiyi is the lead author of CacheWarp, where I contributed exploit development expertise. The message didn’t seem unusual at first — I replied and moved on.

As a side note, the deadlines for USENIX Security ‘26 would soon become relevant:

• Paper registration due: August 19, 2025
• Paper submission due: August 26, 2025

A few days later, while recovering from an illness, my mind wandered back to Ruiyi’s question. Something felt off. CacheWarp had been published more than a year earlier — why ask about sudo now?

Unless they had found something new.

After recovering, I reached out:

August 21, 2025 Youheng Lü – 10:49 AM “Hey, where did this question come from? Are you looking into sudo?”

Ruiyi Zhang – 10:57 AM “Yes, we are looking if there are any useful gadgets for another paper.”

After a few more messages, the situation became clear. Their team had discovered a new exploit primitive and wanted to build a sudo exploit around it. The primitive was conceptually simple: the attacker could shift the stack pointer (rsp) up and down. While this makes building a traditional ROP chain trivial, the researchers specifically wanted a data-only exploit that preserves control-flow integrity to bypass mitigations like shadow stacks.

They had five days left before the submission deadline.

Data-Only Exploit Overview

One of the biggest challenges in data-only exploitation is that most interesting variables live in registers, not on the stack. However, during CacheWarp exploitation, I had noticed something useful in the Linux kernel:

Dump of assembler code for function entry_SYSCALL_64:
[...]
   0xffffffff8200015e <+222>:    pop    %r8
=> 0xffffffff82000160 <+224>:    pop    %rax <= HERE.
   0xffffffff82000161 <+225>:    pop    %rcx
   0xffffffff82000162 <+226>:    pop    %rdx
   0xffffffff82000163 <+227>:    pop    %rsi

The return value of a system call is temporarily stored on the stack and then loaded into rax via pop rax in entry_SYSCALL_64.

During CacheWarp, we didn’t end up using this observation. But it suddenly became highly relevant.

From previous work, we already knew that if we can force getuid() to return 0, we can exploit sudo. After a getuid call, the stack layout looks like this:

--------
|    0 |
| ---- |
| 1000 | <- rsp
--------

By shifting rsp upward, we can cause pop rax to load 0 into rax. We then shift rsp back to its original position to preserve control-flow integrity. The result is a data-only manipulation of the syscall return value.

Tracking the exact line of code and validating the proof of concept in GDB took about two hours, thanks to the excellent kernel debugging setup from pwn.college. Ruiyi now had a working data-only exploit primitive.

Over the next four days, the team engineered a full exploit using the real hardware primitive. The paper was accepted with only minor revisions. I was also added to the CVE credits, which I’m very grateful for.

Takeaways

This experience reinforced two important lessons:

1. No knowledge or effort is wasted. Kernel internals I explored a year earlier suddenly became critical to exploiting a new vulnerability.
2. Stay curious. If I hadn’t questioned that initial message, I might have missed the opportunity to contribute.

Research progress often depends on connecting old insights with new discoveries. StackWarp was a perfect example of how prior experience can dramatically accelerate exploitation when time is limited.

Conclusion

At SCHUTZWERK, we have highly skilled experts who specialize in rapid prototyping of exploits for hardware and software vulnerabilities. If you are interested in our expertise, schedule a free initial consultation .

~ Youheng Lü