CVE-2026-99999 is just the first in a long list of KVM-specific vulnerabilities since the summer. As more and more people are going to be choosing to put their AI agents into a AI Agent sandbox (oftentimes running Xen or KVM under the hood), this blog talks through the strengths and possible shortcomings of both virtualisation technologies.

Hello,

I found a guest-triggerable host-kernel panic in KVM's x86 shadow MMU. I reproduced it on Linux 6.1.74 and on pre-fix mainline. An attacker with kernel-level control of an L1 guest can reach it; my reproducer uses nested VMX/EPT, Q35 SMM, and two vCPUs.

Q35 compatibility SMRAM lets the normal and SMM KVM address spaces access the same backing guest page. KVM write-tracks a nested-EPT page directory in its normal-address-space memslot. On a write through SMM, mmutrytounsyncpages() checks only the SMM memslot for write tracking, but then searches the VM-wide shadow-page hash. It consequently marks the normal address space's level-2 shadow page unsync, although the sync path expects unsync pages to be level 1.

The reproducer shadows the EPT directory in the normal address space, changes an entry through an SMI handler in SMM, and reuses the directory under another EPT root. When KVM later synchronizes that upper-level shadow page, it treats a non-leaf SPTE as a leaf. dropspte() takes the leaf reverse-map removal path, and ptelistremove() executes BUG() because that reverse map does not own the SPTE. On the tested 6.1.74 host this ends in a fatal kernel panic:

WARNING: mmutrytounsyncpages WARNING: eptsyncpage RIP: ptelistremove Kernel panic - not syncing: Fatal exception

The bug was introduced by commit 699023e23965 ("KVM: x86: add SMM to the MMU role, support SMRAM address space"). Upstream commit 0f38453cdb2e checks write tracking in both x86 address spaces and is included in v7.2. The adapted 6.1.y backport is commit 09aa68552d25, included in v6.1.187. The companion upstream commit 2e8a2c1b0306 fixes a newer hugepage fast-path check; that fast path is not present in 6.1.74.

Upstream fix: https://github.com/torvalds/linux/commit/0f38453cdb2e17566ccb7c0f3dabd5bd21caca26

6.1.y backport: https://github.com/gregkh/linux/commit/09aa68552d2542cc6c23edd1568ac265dc5d886f

Regards, Jinu Kim

A KVM guest using SEV-ES or SEV-SNP with multiple vCPUs can trigger a double fetch race condition vulnerability and invoke the VMGEXIT handler recursively. If an attacker manages to call the handler multiple times, they can theoretically trigger a stack overflow and cause a denial-of-service or potentially guest-to-host escape in kernel configurations without stack guard pages (CONFIGVMAPSTACK).