CVE-2026-46036

What it actually does

Race condition allowing concurrent VFIO_DEVICE_SET_IRQS ioctls to free the cdx_irqs array via vfio_cdx_msi_disable while another path still holds a reference, resulting in use-after-free.

Why it matters to the business

Local attackers may crash systems or escalate privileges, leading to service outages or full host compromise in environments using VFIO CDX devices.

How an attack unfolds

An attacker with local access issues multiple concurrent VFIO_DEVICE_SET_IRQS calls against a VFIO CDX device; one call observes config_msi as set while another clears it and frees cdx_irqs, enabling use-after-free exploitation for code execution.

How to fix it

Apply a kernel update that adds the cdx_irqs_lock mutex to serialize all updates to config_msi, cdx_irqs, and msi_count in vfio_cdx_set_msi_trigger and removes the unsynchronized test in vfio_cdx_irqs_cleanup.

How to confirm the fix worked

Inspect the vfio_cdx_device struct and vfio_cdx_set_msi_trigger function in the kernel source to confirm the mutex is declared and held around config_msi checks and cdx_irqs operations.

Typical attack path

1. Gain local user access on a Linux system
2. Locate or configure a VFIO CDX device
3. Trigger concurrent VFIO_DEVICE_SET_IRQS ioctls to induce the race
4. Leverage the resulting use-after-free for privilege escalation or denial of service

How to detect it

Examine kernel logs and audit trails for repeated or concurrent VFIO_DEVICE_SET_IRQS ioctl patterns on CDX devices, especially around device open/close events.

What your security team should do

• Prioritize kernel updates on systems exposing VFIO CDX devices
• Limit untrusted local access to VFIO device nodes
• Review audit logs for high-frequency VFIO ioctl activity