Submitted ⁨⁨3⁩ ⁨days⁩ ago⁩ by ⁨SirHaxalot@nord.pub⁩ to ⁨cybersecurity@infosec.pub⁩

https://github.com/V4bel/Januscape/blob/main/assets/write-up.md

Januscape: Guest-to-Host Escape in KVM/x86

Januscape (CVE-2026-53359) is a guest-to-host vulnerability that exploits a use-after-free in the shadow MMU emulation of KVM/x86. Guest-side actions alone can trigger the bug and corrupt the shadow page state of the host kernel that runs the guest. Because the vulnerability lives in the shadow MMU code that x86 KVM shares between both Intel (VMX) and AMD (SVM), it is not limited to a single architecture, and to the best of public knowledge, this is the first guest-to-host exploit research triggerable on both Intel and AMD. It threatens the guest-host isolation of multi-tenant x86 public clouds (GCP, AWS, etc.) that accept untrusted guests and expose nested virtualization. In fact, this vulnerability was used as a 0-day in Google kvmCTF.

source

Comments

Sort:hotnew top

SirHaxalot@nord.pub ⁨3⁩ ⁨days⁩ ago
At least it sounds like a full escape is not trivial still

Turning this vulnerability into a full escape is difficult work, because the primitive is tricky. The page that gets reoccupied is the spt of a shadow page that was zapped, returned to buddy, and then refilled. After it is freed, KVM installs no more leaf SPTEs on this page, so the only remaining write is the single fixed constant (on x86-64, 0x8000000000000000) that clears the orphaned parent pointer, and the guest only decides which slot (offset) to write to. Because of this, one must carefully choose a guest-side cross-cache object where that fixed write aligns to a meaningful field, and depending on how the object is allocated it can be dependent on the guest VM’s RAM quota.

Because of this tricky primitive, each architecture must be exploited in a different way, and empirically, the AMD-specific exploit is a little easier.

source