I found a KVM guest-to-host heap corruption bug and someone else got there first :: Himanshu Anand :: Security & Other Notes
I found a KVM guest-to-host heap corruption bug and someone else got there first
2026-08-10 ::
Himanshu Anand
:: 23 min read (4844 words)
#security
#kvm
#sandbox
#vulnerability
Table of Contents
TLDR⌗
I independently found a heap out-of-bounds read/write in KVM’s SEV-SNP Page State Change handler. A malicious guest VM can corrupt host kernel heap memory and leak its layout, across the VM boundary, as many times as it wants. I reported it to [email protected] on May 9, 2026 and they told me someone else reported it a few weeks earlier.
This post is the story of that bug, why my fix was wrong, why theirs was better, how bad this thing actually is, and what you can learn from all of it. I also built a safe CTF challenge so you can practice the same primitive without setting anything on fire.
CVE-2026-53360. Fixed in mainline commit db3f2195d293. Affected every kernel with SNP PSC support since ~v6.10. Patched in v7.0.12, v6.18.35, v6.12.93.
I found a VM escape bug and got an email which hurt my feelings⌗
I have been reading KVM code on and off for a while. Not because I enjoy pain (becasue I got no day job), but because the hypervisor boundary is one of the most interesting attack surfaces in modern computing. A bug there means a guest can punch through the wall and mess with the host and that’s the whole game. (Kinda wow, you spin up a VM in cloud and pwned whole cloud. Is this what they call the God syndrome?? )
In early May I was staring at arch/x86/kvm/svm/sev.c, specifically the Page State Change handler for SEV-SNP guests. If you do not know what any of those words mean, do not worry, I will try to explain all of it in a minute. TLDR is : SNP guests talk to the host through a shared page called the GHCB and PSC is one of the things they can ask for. The host parses a buffer the guest provides and the buffer has a header and an array of entries.
I noticed something that made me sit up. The guest gets to choose how big the buffer is, The host allocates exactly that many bytes But then the host loops over the entries using a count from the header and the only bounds check on that count is against a protocol constant (253)and not against the size of the buffer it just allocated.
So, if the guest says “here is an 8-byte buffer” and then says “please process 252 entries,” the host happily walks 2 KB past the end of an 8-byte allocation into whatever else is sitting on the kernel heap.
I wrote a proposed fix and I verified it compiled cleanly, sent it to [email protected] on May 9. I felt pretty good about myself (oh! no god syndrome again).
Then I got this back:
Hi Himanshu, this was reported already a couple weeks ago. It’s not an easy fix because the issue is bigger than what you found. Sorry about that, I appreciate trying to work on the fix!
If you have read my post about disclosure timelines, you know this feeling. I talked about being reporter number eleven on a different bug. This time I was reporter number two Progress, I guess.
The first reporter was Stan Shaw, who reported this on April 8, about a month before mine. He got the CVE (CVE-2026-53360), he got the Reported-by credit in the commit and he published a detailed writeup and a PoC. His analysis was thorough and his PoC produced 73 KASAN reports from a single insmod. Credit where it is due.
But the part that stung was not losing the CVE. It was the second sentence: “the issue is bigger than what you found.”
That turned out to be completely true, and understanding why taught me more than finding the bug did.
okay but what even is SEV-SNP (the 5 minute version)⌗
If you already know what SEV-SNP is, skip ahead. If you do not, here is the minimum you need to follow the rest of this post.
AMD makes server chips called EPYC. Starting with the Milan generation (2021), these chips support something called SEV-SNP: Secure Encrypted Virtualization with Secure Nested Paging.The idea is simple: the guest VM’s memory is encrypted with a key that even the hypervisor cannot read. The CPU hardware enforces this, hypervisor is treated as untrusted.
This is built for cloud computing, uou are running your workload on someone else’s server, do not trust the cloud provider, do not trust their hypervisor.<br>SEV-SNP says: We will encrypt your memory so even if the hypervisor is compromised, your data stays private. Nice one
That is the marketing pitch And reality, hardware does enforce it.
But here is the thing nobody puts in the marketing materials: the host also has to defend itself against the guest. The whole point of confidential computing is running someone else’s code that you do not trust. The guest is untrusted from the host’s perspective too. Both directions matter.
This bug is in the second direction Guest attacks host. The...