Zapscape (CVE-2026-64561): Guest-to-Host Escape in KVM/x86
1–10 of 14 posts
Re: Zapscape (CVE-2026-64561): Guest-to-Host Escape in KVM/x86
#2Another serious critical vulnerability that almost no-one cares about, when they should.
Re: Zapscape (CVE-2026-64561): Guest-to-Host Escape in KVM/x86
#3Oh yay another one lol. This one seems much more general than the prior one that needed nested page tables.
Patch Thursday for cloud VM ppl lol
Re: Zapscape (CVE-2026-64561): Guest-to-Host Escape in KVM/x86
#4Oh yay another one lol. This one seems much more general than the prior one that needed nested page tables. Patch Thursday for cloud VM ppl lol
Do most cloud providers have live-migration or what is the approach to make this seamless? What kind of interruption might tenants notice?
Re: Zapscape (CVE-2026-64561): Guest-to-Host Escape in KVM/x86
#5Oh yay another one lol. This one seems much more general than the prior one that needed nested page tables. Patch Thursday for cloud VM ppl lol
Do most cloud providers have live-migration or what is the approach to make this seamless? What kind of interruption might tenants notice?
It depends. If you have a plain old VM with no GPU and networked storage it's easy to migrate. If you're using low latency HW on the host it gets a lot trickier. Kuberenetes or some other fleet management helps there, you spin up new nodes and drain the old ones as capacity allows. If you have your PodDisruptionBudgets set right you won't notice much.
You can also use ksplice to live patch the vulnerable kernels as a first aid. I'm not an expert but I think there are some limits to what you can accomplish with it. Also guessing that the embargo period allows the big names to roll the patches out gradually enough that you won't see any panic shutdowns.
Re: Zapscape (CVE-2026-64561): Guest-to-Host Escape in KVM/x86
#6Every LLM bug in the Linux kernel (warehouse rave edit).
(This comment is a reference to https://youtu.be/v1Mfirg2-Z8
Re: Zapscape (CVE-2026-64561): Guest-to-Host Escape in KVM/x86
#7Oh yay another one lol. This one seems much more general than the prior one that needed nested page tables. Patch Thursday for cloud VM ppl lol
Doesn't this one need it as well? I see the shadow mmu
Re: Zapscape (CVE-2026-64561): Guest-to-Host Escape in KVM/x86
#8Oh yay another one lol. This one seems much more general than the prior one that needed nested page tables. Patch Thursday for cloud VM ppl lol
Do most cloud providers have live-migration or what is the approach to make this seamless? What kind of interruption might tenants notice?
Yeah most cloud providers have live migration and a reasonably-well-tested playbook for updating the node kernel + hypervisor.
Re: Zapscape (CVE-2026-64561): Guest-to-Host Escape in KVM/x86
#9Oh yay another one lol. This one seems much more general than the prior one that needed nested page tables. Patch Thursday for cloud VM ppl lol
Doesn't this one need it as well? I see the shadow mmu
Right, but what x86 KVM setup is there in practice that doesnt present a mmu to its guest and hence keep its own track (shadow) of memory mappings?
Re: Zapscape (CVE-2026-64561): Guest-to-Host Escape in KVM/x86
#10Earlier quoted context omitted.
Doesn't this one need it as well? I see the shadow mmu
Right, but what x86 KVM setup is there in practice that doesnt present a mmu to its guest and hence keep its own track (shadow) of memory mappings?
Shadow memory mappings are only needed when you do not have hardware virtualization or when doing nested virtualization.
From the page: "it can threaten the guest-host isolation of KVM/x86 hosts that accept untrusted guests and expose nested virtualization"
That is not to say that it is not a serious vulnerability though.