SEV-ES / SEV-SNP guest kernel - unsolicited #VC (vector 29) injection: MULTI-TENANT ISOLATION: An untrusted hypervisor

Impact

MULTI-TENANT ISOLATION: An untrusted hypervisor can inject the #VC exception (vector 29) into an SEV-ES or SEV-SNP guest at a moment of its choosing and force the guest's #VC handler to run in an unexpected context. The handler is privileged guest code that touches the GHCB shared page, so a host that controls when it fires gains a lever on guest execution - the WeSee research turned this class into reading and writing confidential guest memory and executing code inside the VM. The guest's own hardware isolation is what gets used against it.

Who can reach it

Malicious or compromised hypervisor against its own guest. No guest bug required and no tenant cooperation - the host simply injects.

What to do

Fixed in the **guest** kernel, not the host - the hardening lives in the SEV-ES/SNP guest's #VC handler and interrupt entry code. That inverts the usual rollout: you can patch every hypervisor you own and still be exposed, because the protection has to be in the tenant's own VM image. As an operator your job is to ship updated confidential-guest images (or tell tenants which minimum kernel to run) and, where you can, enforce it as an admission requirement. Each guest picks the fix up on its next boot; no host reboot, no firmware update. Fixed in Linux 6.9 and backported; guests must run a kernel that hardens the #VC entry path. As the operator you cannot fix this for a tenant who brings their own image - the honest control is to document a minimum guest kernel and enforce it at admission for confidential workloads.

References