SEV-ES / SEV-SNP guest kernel - injection of virtual interrupts 0 and 14: MULTI-TENANT ISOLATION: An untrusted

Impact

MULTI-TENANT ISOLATION: An untrusted hypervisor can inject virtual interrupts 0 (divide error) and 14 (page fault) into an SEV-SNP or SEV-ES guest at arbitrary points, reaching userspace signal handlers - in particular SIGFPE - inside the confidential VM. The Heckler research showed this class turning into authentication bypass inside the guest: inject an interrupt at the right instruction and a login check returns the wrong answer. The host never touches guest memory, so no memory-integrity mechanism catches it.

Who can reach it

Malicious hypervisor against its own guest. Requires timing precision but no guest vulnerability.

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 by guest-kernel hardening (Linux 6.9+ restricts which interrupts a guest accepts from the hypervisor). Enable Restricted Injection where the platform and guest support it. Again this is a guest-image problem, so operators should publish a minimum kernel and gate confidential workloads on it rather than assuming host patching covers them.

References