CVE-2024-27437

What it actually does

Race condition in vfio/pci INTx IRQ handling allows the disable depth to be incremented twice when an interrupt fires in the window between request_irq() auto-enable and subsequent masking on devices lacking DisINTx support, resulting in an unrecoverable state where the masked flag blocks nested enables.

Why it matters to the business

Systems using VFIO for device passthrough in virtualized or containerized workloads on affected kernels can experience unrecoverable interrupt handling failures, leading to device unavailability and operational disruption until the system is updated.

How an attack unfolds

An attacker with local access on an affected system triggers the IRQ masking window on a device without DisINTx support, causing the double-disable condition that prevents recovery through the VFIO interface.

How to fix it

Upgrade linux-aws-5.4 on Ubuntu Pro 18.04 LTS to version 5.4.0-1135.145~18.04.1 or later. Reboot the system after installation to load the patched kernel.

How to confirm the fix worked

Verify the running kernel version matches or exceeds the fixed release, confirm the vfio-pci module loads without errors related to IRQ auto-enable, and test device passthrough functionality to ensure INTx masking behaves correctly.

Typical attack path

1. Obtain local access to a system running an affected Linux kernel with VFIO PCI passthrough enabled
2. Attach or interact with a PCI device requiring INTx masking at the irqchip
3. Trigger interrupt events during the auto-enable window before masking completes
4. Force the IRQ disable depth to increment twice, rendering the interrupt unrecoverable

How to detect it

Review kernel logs for VFIO IRQ disable depth warnings or unrecoverable interrupt states on systems with device passthrough; no specific post-exploitation artifacts are publicly documented.

What your security team should do

• Prioritize patching all affected systems to the specified fixed kernel version within standard change windows
• Audit environments using VFIO device assignment for exposure and schedule reboots
• Monitor upstream kernel changelogs for related VFIO interrupt fixes