In early 2024, a serious vulnerability—CVE-2024-25743—was discovered in the Linux kernel up to version 6.9. This flaw allows an untrusted hypervisor to mess with virtual machines running on AMD SEV-SNP and SEV-ES systems. Specifically, it can inject certain interrupts in guests that can interfere with applications, even making them crash or misbehave.

If you use virtualization, especially with confidential workloads, this is something you need to know about. This post gives a simple breakdown of the bug, shows some working code, and references the original discoveries and discussions in the Linux security community.

The Basics: What’s the Problem?

In virtualized environments, the hypervisor controls what hardware events (like interrupts) get delivered to each virtual machine (VM). AMD SEV-SNP and SEV-ES are hardware features designed to keep VMs isolated and protected from the hypervisor—even if the hypervisor is malicious.

But in Linux kernel versions through 6.9, it’s possible for a malicious hypervisor to *inject virtual interrupts*—specifically, interrupts (divide-by-zero) and 14 (page fault)—into guest VMs at any time. That means:

The hypervisor can force the guest kernel to think a divide-by-zero happened when it didn’t.

- Interrupt triggers a SIGFPE signal in userspace, causing apps to crash, behave oddly, or be a target for exploitation.

These interrupts are supposed to be under the VM’s control, not the hypervisor’s. By injecting them, the hypervisor can break the security model that SEV-SNP and SEV-ES promise.

How Does the Exploit Work?

Let's look at how this can be exploited in the wild.

A hypervisor with knowledge of this bug can *inject* a virtual interrupt (say, for divide-by-zero) into a running VM at any point. In the Linux guest, this results in a signal being delivered to the running userspace process, as if it had triggered an actual divide-by-zero. Many apps are not prepared for unexpected signals, so this can crash servers, disrupt cron jobs, or even potentially allow further exploits.

Suppose you have a basic C program running inside an affected VM

#include <stdio.h>
#include <signal.h>
#include <stdlib.h>

void sigfpe_handler(int signum) {
    printf("Got SIGFPE! Process will exit.\n");
    exit(1);
}

int main() {
    signal(SIGFPE, sigfpe_handler);
    printf("Program running. PID: %d\n", getpid());
    while (1) {
        // Simulating work
    }
    return ;
}

When this is running in a protected VM, a malicious hypervisor could *inject* a divide-by-zero interrupt () into the vCPU’s register state. Linux's low-level CPU traps will notice this and deliver a SIGFPE to the userspace process, invoking sigfpe_handler as if an actual illegal math operation had occurred.

(Pseudo) Exploit Code: Hypervisor Side

While the details depend on your hypervisor and kernel setup, the attack involves sending INTR or 14 via VM control APIs. For example, a pseudo-code function in a malicious hypervisor could look like this:

# Pseudo-code: Sends IRQ  (divide by zero) to a running vCPU

def inject_event_to_vm(vm_id, vcpu_id, vector_num):
    # Hypothetical hypervisor API
    hypervisor_api.inject_interrupt(vm_id, vcpu_id, vector_num)
    
# In the real exploit, vector_num= causes divide-by-zero, 14 triggers page fault.
inject_event_to_vm(target_vm, target_vcpu, )

This operation should be impossible in a *truly isolated* VM, but thanks to CVE-2024-25743, it's possible in Linux through 6.9.

Why Does This Matter?

- Breaks Isolation: SEV-SNP/ES are supposed to guarantee that even a bad hypervisor can't mess with your VM.

Crashes Apps: Imagine a process on a production server getting hit with a SIGFPE out of nowhere.

- Could Lead to More Attacks: Reliable delivery of unexpected signals can help attackers develop privilege escalation or DoS exploits.

Are you on shared, cloud, or otherwise potentially untrusted infrastructure?

If so: upgrade your kernel as soon as a patched version is available.

How to Defend Right Now

- Upgrade the kernel: Track kernel.org and distributions for patches.

References & Further Reading

- CVE Record: NIST CVE-2024-25743
- Upstream Discussion: LKML Patchset and Thread, bugzilla.redhat.com bug 2268745
- AMD SEV-SNP Introduction: AMD SEV-SNP Whitepaper
- General Kernel Security: Linux Kernel Documentation: Speculative Execution Side Channel Mitigations

Closing Thoughts

CVE-2024-25743 is a reminder that "hardware-based" isolation isn’t a silver bullet, especially when software doesn't honor it. If you operate confidential VMs or rent cloud infrastructure, keep a close eye on kernel updates and the security advisories from both your distribution and hardware vendors.

For developers: always check what signals your apps might receive—and be paranoid when running under someone else’s hypervisor!

Stay safe, stay updated.

*Written for general Linux and cloud security readers by an AI assistant up-to-date as of June 2024. Content exclusive, simple, and to the point.*

Timeline

Published on: 05/15/2024 18:15:10 UTC
Last modified on: 08/15/2024 16:35:04 UTC