Linux guest kernel - hypervisor-injected int 0x80 on the 32-bit syscall path (SEV-SNP / SEV-ES, AMD-SB-3008): The

Impact

The higher-scoring half of Heckler. A malicious hypervisor injects interrupt 0x80 - the legacy 32-bit syscall gate - into a confidential guest at a chosen instruction, and the guest kernel services it as a real syscall. The researchers turned this into an OpenSSH authentication bypass and a sudo-to-root escalation *inside* the confidential VM, with the host never touching guest memory. At 8.8 with a changed scope this is the most severe confidential-guest issue in the set, and it also covers Intel TDX, so it is a property of the interrupt-delivery design rather than an AMD-only bug.

Who can reach it

Malicious or compromised hypervisor injecting interrupts into its own guest. No guest vulnerability and no tenant cooperation needed.

What to do

**Guest kernel fix, not a host fix** - Linux 6.6.7 / 6.9 and later carry the int80 hardening series. That inverts the usual rollout: patching every hypervisor you own does nothing, because the protection has to live in the tenant's VM image. As the operator, publish a minimum guest kernel for confidential workloads and gate admission on it. A quicker guest-side control is to disable 32-bit x86 emulation in the guest kernel entirely, which removes the int 0x80 gate. The hardware answer - protected/restricted interrupt delivery - had no mainline Linux support at disclosure. No host reboot, no firmware, no BIOS.

References