CVE-2024-26810 - Race Condition in Linux VFIO PCI INTx Handling Explained

CVE-2024-26810 is a vulnerability found in the Linux kernel's VFIO (Virtual Function I/O) PCI driver related to the handling of legacy INTx interrupts. Specifically, a race condition could occur between handling changes to interrupt masking through PCI configuration space and user actions via ioctl calls. This race could lead to inconsistent interrupt states and unexpected behavior.

This post will break down what this bug is about, show some affected code patterns, reference the original report, and describe how this issue could be exploited—and how it got fixed.

Background: VFIO and INTx Interrupts

- VFIO (Virtual Function I/O) is a Linux kernel framework that exposes direct device access to user space. It is key to hardware virtualization (e.g., passthrough to KVM/QEMU guests).
- INTx interrupts are the old-school, legacy interrupt lines (compared to MSI/MSI-X). Sometimes devices or VM setups still use them.

Via user ioctls (userspace, e.g. QEMU)

But: Both of these paths could change interrupt state at the same time unless properly locked.

Here’s a simplified code pattern (not real in-tree code, but conveys the idea)

// This is a simplified illustration
void vfio_pci_mask_intx(struct vfio_pci_device *vdev)
{
    /* mask operation through config space (no locking before) */
    vdev->irq_type = PCI_IRQ_INTX;
    pci_write_config_word(vdev->pdev, PCI_COMMAND, mask_val);
}

void vfio_pci_set_intx_ioctl(struct vfio_pci_device *vdev, int enable)
{
    /* Change via ioctl, no serialization with above */
    if (enable)
        vdev->irq_type = PCI_IRQ_INTX;
    else
        vdev->irq_type = PCI_IRQ_NONE;
}

If both of those functions run at once—it’s undefined which state the kernel believes!

The Patch: Add igate Lock

The fix introduces a locking mechanism (igate, a mutex) so that all changes to the interrupt configuration are serialized. Now, whenever the code tests or changes INTx state, it must hold the lock.

Example Patch Snippet

mutex_lock(&vdev->igate);
if (is_intx(vdev)) {
    // do INTx-specific work
}
// ...
mutex_unlock(&vdev->igate);

Now, both config space and IOCTL paths grab igate so the race is eliminated.

Disable or enable interrupts unexpectedly

- Cause inconsistent device behavior, potentially leading to Denial-of-Service, information leaks, or escalating to further bugs if device state is confused

In cloud or virtualized hosting, where guest VMs get hardware directly via VFIO, reliable interrupt delivery is very important for security isolation.

References

- CVE-2024-26810 at MITRE
- Linux kernel commit fixing CVE-2024-26810
- Patch discussion on LKML

Conclusion

CVE-2024-26810 highlights the kind of subtle race conditions that can affect low-level system code like the Linux kernel's VFIO subsystem. The fix was to ensure all changes to INTx interrupt state are protected by a lock, so no two threads can update or check the state at once.

If you run VFIO on your system (KVM/QEMU passthrough, etc.), be sure to update to a kernel version including this fix.


For more info, read the original commit and stay safe!

Timeline

Published on: 04/05/2024 09:15:09 UTC
Last modified on: 11/06/2024 20:35:09 UTC