CVE-2024-2494 - Uncovering a Dangerous Denial-of-Service Flaw in Libvirt’s RPC Library

In March 2024, a new vulnerability was found in a widely used open-source virtualization toolkit – libvirt. The flaw, idenfitied as CVE-2024-2494, exists in libvirt’s RPC (Remote Procedure Call) library APIs and allows a local, unprivileged user to crash the libvirt daemon, effectively causing a denial-of-service (DoS) on the host system. This post will break down the issue in simple terms, include relevant code snippets, and explain how it can be exploited in real-world scenarios.

What is CVE-2024-2494?

Libvirt’s RPC library is responsible for communication between processes – for example, between the libvirtd daemon and client programs. A flaw exists in the way the RPC server deserialization code processes incoming data. The problem is that memory for arrays is allocated before the API checks that the requested size is non-negative. That means, if an attacker passes a negative length, the allocation function (g_new) interprets the negative value as a very large positive number (due to integer underflow), leading to a crash or even worse outcomes.

In summary:
Any local, unprivileged user can talk to the libvirt daemon and intentionally send a malformed request that makes the daemon crash due to this flaw.

Why Is This Dangerous?

Libvirt is at the core of many modern virtualization stacks, like KVM and QEMU. If the libvirt daemon gets taken down, all management of virtual machines stops. In a multi-tenant or shared environment (like a cloud server), this lets any user crash all virtualization for everyone else.

Let’s take a closer look at the problematic code region

// Simplified example for demonstration
int n_elements;
...
// Reading n_elements from the RPC message (attacker-controlled)
memcpy(&n_elements, buf, sizeof(int));

// ALLOCATE ARRAY -- PROBLEM: No negative check before allocation!
MyType *array = g_new(MyType, n_elements);

if (n_elements < ) {
    // Invalid length, should not proceed
    return -1;
}

// ... (rest of deserialization)

If n_elements is negative (say, -1), it’s passed to g_new.

- On most C libraries, this negative value wraps around to a giant unsigned value (for 32-bit it becomes 4,294,967,295).

Exploit Details

Who can exploit it?
Any local user with permission to connect to the libvirt UNIX socket (common on multi-user Linux machines).

How does exploitation work?
A custom client can send a crafted RPC request where a size field is set to a negative integer. When the libvirt daemon processes this message, it tries to allocate an impossibly large memory buffer. This causes it to crash with an out-of-memory error or free-list corruption.

Simple Proof-of-Concept (PoC) snippet

> Note: This is for educational use only, never run against production servers.

import socket
import struct

LIBVIRT_SOCKET = "/var/run/libvirt/libvirt-sock"

# Create a malicious message: negative length in element count
msg = b'\xab\xcd\xef...'  # Protocol header (not shown)
msg += struct.pack("<i", -123456)  # Malicious negative number

s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
s.connect(LIBVIRT_SOCKET)
s.send(msg)
s.close()

This example sends a message to the libvirt daemon with a deliberately negative integer where a length should be. As a result, the daemon will likely crash.

Official Sources and References

- Red Hat Security Advisory – CVE-2024-2494
- libvirt git commit fixing CVE-2024-2494 (see official repo)
- libvirt Bugzilla entry

The patched version checks for negative array lengths *before* memory allocation.

- On Red Hat/Fedora:

  sudo dnf update libvirt
  

- On Debian/Ubuntu

  sudo apt update
  sudo apt install libvirt-daemon
  

As a workaround:
Restrict socket access to only trusted users. For example, adjust permissions on /var/run/libvirt/libvirt-sock so that only admin users or VMs runners can access it.

Conclusion

CVE-2024-2494 is a classic example of what goes wrong when untrusted user input isn’t fully checked before memory allocation. While it doesn’t allow full remote code execution, the ability to crash libvirt can seriously disrupt multi-user virtualization hosts or cloud servers. Always keep your critical system components like libvirt up-to-date and review permissions on daemon sockets to minimize risk.

Stay safe, patch early!

> *If you want more details or have questions about mitigation, leave a comment or see the official Red Hat and libvirt links listed above.*

Timeline

Published on: 03/21/2024 14:15:10 UTC
Last modified on: 04/01/2024 13:17:05 UTC