QEMU is a popular open-source emulator and virtualizer that’s used in cloud systems and development environments everywhere. However, in the heart of its code, a serious flaw—CVE-2024-26328—affects versions from 7.1. through 8.2.1, especially when dealing with PCI devices and SR-IOV (Single Root I/O Virtualization). This post will break down what went wrong, show you how the bug can be hit, and explain the security risks.

What is CVE-2024-26328?

When configuring PCI devices for virtual machines, QEMU allows guests to use SR-IOV, which gives a physical PCI device multiple “Virtual Functions” (VFs). These are like tiny, lightweight PCI devices guests can use independently.

But here’s the catch:
Inside QEMU, the function register_vfs (in hw/pci/pcie_sriov.c) is supposed to set up each VF and crucially update NumVFs (the PCI register field indicating how many VFs exist) to match the actual total. But due to a coding slip, it fails to update this field correctly—it leaves NumVFs unset or set to the wrong value. So, guest code (and QEMU’s nvme/ctrl.c code) that tries to create, access, or control VFs ends up thinking there are fewer (or more!) VFs than reality.

This weird mismatch breaks assumptions in QEMU’s logic and lets a guest do things it shouldn’t (sometimes leading to out-of-bounds access or DoS).

The bad code looks like this (simplified for clarity)

// hw/pci/pcie_sriov.c
void register_vfs(PCIDevice *dev, int num_vfs) {
    // ... snip ...

    // Should set NumVFs to total VFs allowed
    // MISSING:
    // pci_set_word(dev->config + PCI_SRIOV_NUM_VFS, PCI_SRIOV_TOTAL_VF);

    // ... rest of code ...
}

So, instead of telling the world (and QEMU subsystems) that “you have X virtual functions,” this field is left zero or wrong.


## How Does It Affect nvme/ctrl.c?

QEMU’s NVMe controller code (hw/nvme/ctrl.c) queries the amount of possible VFs for PCI passthrough and resource allocation. If this number is wrong, it can:

Allocate not enough or too much memory.

- Let a guest ask for VFs that don’t exist (crashing QEMU, exposing memory, or causing use-after-free errors).

Example Exploit Scenario

Let’s imagine an attacker controls a guest VM, and QEMU’s register_vfs didn’t set up NumVFs right. The attacker could:

`c

int fd = open("/sys/bus/pci/devices/000:00:10./config", O_RDWR);

`sh

echo 16 > /sys/bus/pci/devices/000:00:10./sriov_numvfs

`

If the QEMU code path expects or a low number, but guest code asks for more, QEMU’s internal logic can walk off the end of an array or misallocate structures. In some scenarios, this can be triggered remotely (from a VM), crashing the hypervisor and possibly leading to elevation of privilege or device state leakage.

Realistic Exploit Impact

- Denial of Service (DoS): Malicious VM can crash QEMU by asking for non-existent Virtual Functions, causing buffer overflows or illegal memory accesses.
- Possibly Info Leak or Privilege Escalation: If an attacker can control how QEMU reads/writes VF entries, they might force it to touch unintended memory if other mitigation isn’t present.

How to Fix

The fix is simple: Ensure register_vfs() always updates the NumVFs field to the total available. This avoids logic confusion later.

Fixed code

void register_vfs(PCIDevice *dev, int num_vfs) {
    pci_set_word(dev->config + PCI_SRIOV_NUM_VFS, num_vfs);  // PATCHED
    // rest of config
}

References and Official Resources

- Official CVE page: NVD entry for CVE-2024-26328
- QEMU mailing list: QEMU-devel - Patch discussion
- Source code: QEMU Git: pcie_sriov.c
- SR-IOV background: Wikipedia - Single-root I/O virtualization

Summary

CVE-2024-26328 is a subtle but impactful bug in QEMU’s PCI SR-IOV code that can be abused by guest systems to crash their hypervisor or possibly corrupt memory. It affects all QEMU users running versions 7.1. through 8.2.1 with SR-IOV devices. Upgrade to a patched QEMU ASAP if you allow PCI passthrough or guests with SR-IOV devices.

If you’re building multi-tenant or cloud setups, watch these “small” bugs—because with virtualization, little numbers can lead to really big problems.


*This write-up is original and aims to make CVE-2024-26328 easy to understand for everyone. If you have questions on QEMU security, drop them below!*

Timeline

Published on: 02/19/2024 05:15:26 UTC
Last modified on: 11/06/2024 15:35:12 UTC