CVE-2024-26810

What it actually does

Race condition between config-space DisINTx masking and ioctl-driven INTx configuration changes allows concurrent updates to irq_type without proper serialization under igate, leading to inconsistent interrupt state and potential kernel instability.

Why it matters to the business

Systems relying on VFIO device passthrough for virtualization or hardware acceleration may experience crashes or degraded availability; the issue affects widely deployed Linux kernel versions, increasing operational risk for cloud and enterprise workloads until patched.

How an attack unfolds

A local attacker with sufficient privileges to issue VFIO ioctls and modify PCI config space triggers the race by simultaneously changing interrupt configuration and clearing DisINTx, bypassing intended locking and causing incorrect eventfd signaling or kernel state corruption.

How to fix it

Upgrade the Linux kernel to a version containing commit 1e71b6449d55179170efc8dee8664510bb813b42 or later; apply the fix that introduces locking wrappers around external INTx masking operations for all affected stable branches.

How to confirm the fix worked

Verify the running kernel contains commit 1e71b6449d55179170efc8dee8664510bb813b42; confirm igate is held during is_intx() checks and that config-space masking paths are now serialized; test VFIO device assignment and interrupt configuration under concurrent load.

Typical attack path

1. Obtain local access with privileges to open VFIO devices and issue ioctls
2. Configure an INTx interrupt via the VFIO interface while concurrently writing to PCI config space to clear DisINTx
3. Exploit the window where is_intx() is evaluated without igate held to induce inconsistent interrupt masking
4. Trigger kernel panic, hang, or denial of service through corrupted interrupt state

How to detect it

Review kernel logs for VFIO interrupt configuration races or unexpected INTx state changes; look for processes issuing rapid VFIO ioctls combined with PCI config writes; correlate with any observed system crashes in virtualization hosts.

What your security team should do

• Prioritize kernel upgrades on all systems exposing VFIO to untrusted workloads within the next maintenance window
• Restrict VFIO device access to only trusted processes using SELinux or AppArmor policies
• Monitor kernel logs for VFIO-related warnings or interrupt storms after applying the fix