On recent Linux kernels, a nasty bug lurked deep in the PCI device virtualization layers, quietly blocking access to hardware for some users. Assigned the ID CVE-2024-27437, this vulnerability involved the VFIO framework and the old fashioned INTx PCI interrupt line. We break down what the bug really was, show you the code and how exploits could manifest, and explain exactly how maintainers fixed it.
What Is the Vulnerability?
The bug involves VFIO's handling of PCI INTx interrupts, specifically when the device lacks modern DisINTx support (that is, can’t itself mask interrupts). On such devices, the kernel “masks” the interrupt at the software irqchip level.
But due to the Linux VFIO code's sequence, an interrupt could slip in between enabling the IRQ line and setting it masked—causing the interrupt disabling counter to be incremented twice. Once this double increment happened, further attempts to unmask/enable the IRQ via VFIO would fail, and the user would lose control over the device interrupt—a form of Denial of Service for that device in a VM passthrough context!
The Old, Vulnerable Sequence
In the previous code, when a PCI device without DisINTx support was used, VFIO would call request_irq() to attach its handler. By default, this immediately enables the interrupt line in the kernel—even if the device’s masked status later requires it to stay disabled.
The kernel then tries to reconcile the masked state (should the IRQ be active or not?), but there’s a short race:
The IRQ’s disable count is incremented twice: once by handler, once by masked status.
After that, kernel keeps the IRQ disabled and the user can’t enable it anymore.
Visual Pseudocode Snippet (Simplified)
// Vulnerable pattern:
request_irq(dev->irq, handler, ..., dev); // enables IRQ immediately, even if masked
if (dev->masked) {
disable_irq(dev->irq); // disables, increments depth
}
...
// Interrupt could happen right here, before masked!
The Patch: IRQF_NO_AUTOEN
To fix this, kernel developers applied the IRQF_NO_AUTOEN flag. This tells the kernel not to enable the IRQ automatically upon registration—so it remains masked until it’s actually safe to unmask.
Patched Snippet
// Safe, fixed pattern:
request_irq(dev->irq, handler, IRQF_NO_AUTOEN, ..., dev); // don't enable yet!
if (!dev->masked) {
enable_irq(dev->irq); // only enable if desired
}
By inverting the logic, VFIO *actively* unmasks/enables only as-needed, preventing the race (the interrupt can never fire before it’s ready).
See the patch commit here: vfio/pci: Disable auto-enable of exclusive INTx IRQ
## Simple Exploit/DoS Scenario
Device lacks DisINTx, so the kernel uses the old sequence.
- With *precise* timing (or heavy I/O), the device signals INTx between request_irq and masking logic.
User may see their device (e.g., passthrough VGA) not respond further or even lock up the VM.
Note: This is not a “remote code execution” hole, but it’s a subtle, real-world DoS in virtualization.
Who’s Affected?
- Linux kernels before the fix with VFIO/PASSTHROUGH setups.
- Most modern hardware with MSI/MSI-X aren’t vulnerable since they don’t use legacy INTx, but older (or certain quirky) PCI/PCIe devices do.
How to Check and What to Upgrade
If you’re using PCI passthrough with VFIO—especially with non-MSI devices—check your kernel logs and stability. If in doubt:
Upgrade your kernel to a version including the patch (March 2024 or later).
- Check for this commit: vfio/pci: Disable auto-enable of exclusive INTx IRQ
References and Further Reading
- NVD: CVE-2024-27437
- Mainline Linux patch commit
- VFIO Kernel Documentation
- Intro to PCI passthrough: Arch Wiki
Conclusion
CVE-2024-27437 is a textbook case of how even small timing and logic errors in low-level driver code can have major real-world impact—especially with modern virtualization workloads. While it doesn’t allow privilege escalation or code execution, losing device interrupt control can have severe knock-on effects for critical services.
If you’re running Linux with VFIO for passthrough, keep your setup safe—make sure your kernel has this patch.
*This post was written exclusively for understanding CVE-2024-27437 based on kernel changelogs and public sources. Tell your sysadmin friends: don’t let a hidden IRQ trip ruin your VM party!*
Timeline
Published on: 04/05/2024 09:15:09 UTC
Last modified on: 03/27/2025 21:37:24 UTC