CVE-2024-24474 - Understanding the QEMU Integer Underflow and Buffer Overflow in SCSI esp_do

QEMU is a critical open-source machine emulator, powering virtualization for countless development, testing, and production environments. On January 4, 2024, a new vulnerability was publicly discussed: CVE-2024-24474. This is a particularly dangerous bug, as it involves an integer underflow that quickly turns into a buffer overflow, potentially allowing remote code execution features under certain circumstances.

In this long read, we’ll break down what this bug really is, how it can be exploited in the real world, and show you code snippets directly related to the issue. No complex jargon—just straight talk.

Affected Software: QEMU before version 8.2.

- Component: SCSI (Small Computer System Interface) emulation (hw/scsi/esp.c)
- Problem: Integer underflow leading to buffer overflow via the esp_do_nodma function with crafted SCSI commands

The Component: SCSI ESP Emulation

QEMU can emulate the ancient (but still used) SCSI ESP controller, a chip connecting storage devices. This emulation is often enabled for compatibility with legacy guest operating systems.

Inside QEMU, the file *hw/scsi/esp.c* handles ESP (Enhanced SCSI Processor) logic. One of its core jobs is to move data from QEMU's internal "FIFO" buffer to the guest OS, either directly (DMA) or manually (non-DMA).

The Vulnerable Function: esp_do_nodma

When QEMU receives a "Transfer Information (TI)" SCSI command with non-DMA mode, it calls the function esp_do_nodma(). Here, it checks the requested transfer length from the guest and matches it against the length of data in its FIFO buffer.

Now, say the guest requests *less* data than is present in the FIFO. If the software isn't careful, the subtraction (async_len - dma_len) could "wrap around" past zero, because of integer underflow, leading the software to think a huge amount of data needs moving—it will read/write outside the buffer by a large amount.

Here’s what the flawed code looks like in simple form (QEMU 8.1.1)

// hw/scsi/esp.c: function esp_do_nodma
uint32_t dma_len = ti_size;     // length the guest wants in the TI command
uint32_t async_len = esp->fifo_len;   // number of bytes in FIFO

if (dma_len < async_len) {
    size_t remain = async_len - dma_len;  // <-- Underflow here!
    // ...
}

If dma_len (requested bytes) is less than what's left in the FIFO (async_len), remain becomes a huge positive value due to unsigned underflow.

With remain now a giant number, followup code will copy or read far past the intended buffer, causing a buffer overflow.

The Exploit: Can This Be Hit from a Guest?

Yes, and that's what makes this bug high-severity.

If you control a guest running inside QEMU (or can trigger device emulation code via I/O software), you can:

Ensure the FIFO in QEMU's SCSI emulation holds a much larger chunk of data (250 bytes or so).

3. When the code hits the underflow (1 - 250), remain becomes huge, causing QEMU to miscalculate buffer sizes and overflow.

Here's a (simplified) outline in pseudo-code

// Guest OS sends crafted command
uint8_t ti_cmd[] = {
    // SCSI opcode for Transfer Information (x10) with target LUN, etc...
    x10, x00, x00, x00, x01, // Length = 1 byte
};
// Most emulators, including QEMU, will treat this as a non-DMA command if set up right

// QEMU inside esp_do_nodma()
if (dma_len /* = 1 */ < async_len /* = 256 */) {
    size_t remain = 1 - 256; // Underflows to a huge value, triggers overflow
    // Copying LOOP: buffer overflow
}

Patch and Solution

The QEMU team moved quickly. In December 2023, the following fix (see upstream commit) was added:

if (dma_len > async_len) {
   dma_len = async_len;
}

And similarly, careful checking is performed to be sure no unsigned underflow will occur.

Upgrade your QEMU to at least 8.2. or newer.

Get the release and official advisories here

- QEMU 8.2. Release Notes
- GitLab Commit with the Fix

Links and References

- QEMU Security Announce
- NVD Entry: CVE-2024-24474
- Debian Security Advisory
- Code Fix Commit
- QEMU 8.2. Release Announcement

Who Is Actually at Risk?

- Cloud Providers: Cloud services using QEMU's SCSI ESP device for virtual machines should update immediately.
- Local Developers/CI with Custom Devices: If you use legacy SCSI devices in testing, this bug can be triggered from within VMs.
- Shared Hosting: Any scenario where guest OSes are not fully trusted can be targeted with this overflow.

*Note*: Not every configuration enables the SCSI ESP (-device esp-scsi), but many modern VM templates still do for legacy support.

Final Thoughts

CVE-2024-24474 is a classic example of how ancient device emulation code can create highly exploitable scenarios in even the most up-to-date open-source systems.

All QEMU users and maintainers should patch immediately. If upgrading is complicated, at minimum disable all legacy SCSI ESP device emulation until patched.

> For more deep dives into virtualization security and fresh CVE breakdowns, follow reputable security blogs or the "oss-security" mailing list.

Stay safe, and update QEMU!

*Post exclusive for this discussion; no copying from other summaries. Want more technical details? Dig into the esp_do_nodma code or read the official QEMU mailing list threads.*

Timeline

Published on: 02/20/2024 18:15:52 UTC
Last modified on: 08/15/2024 21:35:04 UTC