CVE-2024-25742 - Breaking Down the Linux AMD SEV-SNP/ES Virtual Interrupt Injection Vulnerability (Pre-6.9 Kernel)

---

Overview

In early 2024, security researchers uncovered a serious vulnerability in the Linux kernel (before version 6.9) impacting AMD’s SEV-SNP and SEV-ES virtualization technologies. Tracked as CVE-2024-25742, the flaw allows a rogue hypervisor to inject virtual interrupt 29, known as #VC, at virtually any moment, hijacking control flow and potentially compromising the supposed strong isolation guarantees of these secure environments.

In this long-read, we’ll break down the problem, show what code was affected, provide a step-by-step explanation, and let you understand what makes this bug so impactful. We’ll also link to original references and demo a theoretical exploit scenario.

What are SEV-ES and SEV-SNP?

AMD SEV (Secure Encrypted Virtualization) with *Encrypted State* (SEV-ES) and *Secure Nested Paging* (SEV-SNP) extend hardware virtualization so that guest virtual machines (VMs) can keep their memory and state encrypted, even if the host hypervisor is untrusted.

SEV-SNP: Adds memory integrity and stricter protections.

Both rely on the guest OS handling certain virtual interrupts (notably #VC) to cooperate with the hypervisor for necessary operations, without letting the host snoop or interfere.

So, What’s CVE-2024-25742?

Put simply: On Linux systems running vulnerable kernels (<6.9), an untrusted hypervisor can inject a *#VC* (“VMM Communication Exception”, vector 29) at virtually any moment, even if the guest isn’t in a valid state to receive it.

This can cause the guest to run the #VC handler at inappropriate times, possibly in contexts where it can’t recover, crash, or even leak secrets to the hostile hypervisor.

> CVE-2024-25742 Summary: Improper handling of #VC interrupts in Linux SEV-SNP/ES guests allows a malicious hypervisor to inject synchronous exceptions at unsafe times, violating guest integrity and confidentiality.

Typical #VC Flow

Normally, #VC exceptions are generated when the SEV guest must cooperate with the host (like for I/O or MMIO). Upon reception, the guest kernel jumps into its #VC handler, which must be designed to operate correctly no matter where it’s invoked.

The Flaw in Pre-6.9 Kernels

In reality, Linux's #VC handler made *assumptions* about when #VC could occur. For example, there are moments when system state is fragile: during kernel entry/exit, within certain critical sections/locks, or even in user mode. If a #VC arrives at these moments, the handler may crash, deadlock, or expose sensitive data.

An attacker with hypervisor access can just keep injecting #VCs at these critical points, eventually breaking or “escaping” the supposed security walls.

Walkthrough with Code Snippet

Let’s look at what this could look like in the Linux kernel’s exception handling code.

(Below is an illustrative snippet from arch/x86/kernel/sev.c and exception common code.)

// This handler is supposed to catch all #VC exceptions.
dotraplinkage void do_vc(struct pt_regs *regs, long error_code) {
    // PRE-6.9: No filtering or state check before handling #VC
    switch (get_vc_type()) {
    case VC_TYPE_IOIO:
        handle_vc_mmio(regs, error_code);
        break;
    case VC_TYPE_MSR:
        handle_vc_msr(regs, error_code);
        break;
    // ... other cases ...
    default:
        die("Unexpected #VC", regs, error_code);
    }
}

Problem: The kernel does not always check whether it’s "safe" to handle a #VC at this point in execution. It assumes the hypervisor only injects #VCs at allowed times — but *CVE-2024-25742 proved otherwise*.

What the attacker does

1. Identifies Fragile Points: Watches for times when the guest is doing something sensitive (e.g., returning to user mode, holding locks, switching to new secrets, etc.).

Example Pseudocode (Hypervisor Side)

# Pseudocode: Force-inject #VC into guest at bad time
guest_vcpu = get_target_vcpu()
while True:
    if guest_vcpu.is_in_sensitive_region():
        inject_interrupt(guest_vcpu, vector=29)  # #VC
        break

Adds documentation and warnings.

See the relevant patch.

Official References

- CVE-2024-25742 at NVD
- Linux kernel patch: Harden #VC handler
- AMD SEV-SNP Technology Overview (PDF)
- Original Linux Discovery Discussion

Who’s at Risk & What Should You Do?

- All cloud VMs or environments using AMD SEV-SNP or SEV-ES with a Linux kernel prior to 6.9 running on untrusted hosts.

Final Thoughts

CVE-2024-25742 is a stark reminder: even in environments designed for "confidential computing," guest security remains fragile if the host can break assumptions about interrupt delivery.

Patch your kernels, and wherever possible, run confidential workloads only on hosts you trust—or wait for the next generation of stronger SEV designs.

Timeline

Published on: 05/17/2024 22:15:07 UTC
Last modified on: 03/27/2025 20:15:24 UTC