CVE-2026-53322

What it actually does

This is a race condition in the Linux kernel vfio/pci device shutdown path. During close or shutdown of a VFIO PCI device, DMA-BUF-backed access to device BAR resources could remain valid for a very small window after the PCI function was disabled and its Memory Space Enable bit was cleared. Because the BAR resources may become inaccessible or be released for reuse by another driver while a DMA-BUF mapping still exists, a local actor with VFIO/PCI device access could potentially trigger stale device-memory access, unexpected MMIO behavior, resource corruption, information exposure, or denial of service. Exploitation is expected to require local access to VFIO device interfaces and the ability to create or hold DMA-BUF mappings for a passed-through PCI device.

Why it matters to the business

The main operational risk is instability or isolation failure on Linux systems that use VFIO PCI passthrough, such as virtualization hosts, GPU/accelerator passthrough platforms, and systems sharing device memory through DMA-BUF. A successful attack could crash workloads, disrupt host device assignment, interfere with devices being rebound to other drivers, or in worst cases expose or corrupt device-backed memory. The currently provided EPSS score is very low, the issue is not listed in CISA KEV, and no public exploit maturity is indicated, so broad internet-scale exploitation is unlikely; however, environments that allow untrusted users, tenants, containers, or virtual machines to interact with VFIO devices should prioritize patching because the affected boundary is host kernel and device isolation.

How an attack unfolds

An attacker first needs code execution on a Linux system where VFIO PCI is available and where the attacker can legitimately or illicitly access a VFIO device group. They open the VFIO device, obtain or retain DMA-BUF-backed mappings to the PCI device BARs, and then intentionally trigger device close, shutdown, reset, or driver rebinding behavior. In the vulnerable sequence, the kernel disables the PCI function before revoking all DMA-BUF access. The attacker attempts to win the timing window by continuing to access the DMA-BUF while the function's BARs are being disabled or released. If successful, the attacker may access stale or invalid MMIO resources, interact with resources that are transitioning to another driver, or induce kernel/device faults. Practical exploitation is timing-sensitive and environment-specific, and no public exploit is currently indicated by the supplied data.

How to fix it

Apply a Linux kernel update that includes the vfio/pci fix which calls vfio_pci_dma_buf_cleanup() before vfio_pci_core_disable() during device close. Because no package-specific fixed versions were provided, use the fixed kernel versions supplied by the relevant Linux distribution, hardware appliance vendor, cloud image provider, or kernel stable branch. After updating, reboot into the corrected kernel; merely installing the package is not sufficient if the vulnerable kernel remains running. If immediate patching is not possible, reduce exposure by limiting VFIO device access to trusted administrative users only, disabling unnecessary PCI passthrough, avoiding DMA-BUF sharing with untrusted workloads, preventing untrusted tenants from controlling device reset/rebind lifecycles, and using strong device cgroup, udev, and container runtime restrictions around /dev/vfio and related device nodes.

How to confirm the fix worked

Confirm that the running kernel, not only the installed package, contains the vfio/pci fix. Validate with the distribution advisory or kernel changelog for the patch that changes vfio_pci_core_close_device() to clean up DMA-BUFs before disabling the PCI function. Check the active kernel using uname -a and compare it to the vendor-fixed version. On source-based or custom kernels, confirm the relevant vfio/pci code path invokes vfio_pci_dma_buf_cleanup() before vfio_pci_core_disable(). Verify exposure by checking whether vfio-pci is loaded, whether /dev/vfio devices exist, and whether untrusted workloads can access VFIO groups. After remediation, perform controlled VFIO passthrough attach/detach, reset, and shutdown testing while monitoring kernel logs for IOMMU faults, PCI BAR access errors, GPU/device resets, or vfio-related warnings.

Typical attack path

1. Gain local code execution on a Linux system using VFIO PCI device passthrough or DMA-BUF sharing.
2. Obtain access to a VFIO group/device, commonly through /dev/vfio interfaces or a virtualization/device-assignment workflow.
3. Create, receive, or hold DMA-BUF mappings associated with PCI BAR resources exposed through vfio/pci.
4. Trigger VFIO device close, shutdown, reset, hot-unplug, or driver rebinding behavior.
5. Race continued DMA-BUF access against vfio/pci device disablement.
6. Attempt to read, write, corrupt, or fault stale BAR-backed resources during the vulnerable window.
7. Leverage the resulting behavior for denial of service, unexpected device interaction, or potential isolation bypass depending on device and host configuration.

How to detect it

There is no reliable single log entry that proves exploitation of this race condition. Detection should focus on suspicious VFIO activity combined with device teardown anomalies. Review audit logs, EDR telemetry, shell history, hypervisor management logs, container runtime logs, and kernel logs for access to /dev/vfio devices by unexpected users or workloads; repeated opening and closing of VFIO groups; frequent PCI reset, hot-unplug, detach, or driver rebind operations; and kernel messages indicating IOMMU faults, PCI BAR access problems, DMA faults, device resets, or vfio-pci warnings. On virtualization hosts, correlate guest lifecycle events with host kernel faults or device reassignment failures. Investigate any crashes, oopses, GPU resets, accelerator resets, or unexplained host instability occurring during VFIO device detach or VM/container shutdown. If advanced tracing is available, review historical ftrace, eBPF, auditd, or kprobe data for vfio_pci_core_close_device, vfio_pci_core_disable, DMA-BUF export/release activity, and unusually tight loops around VFIO device close/reset operations.

• /dev/vfio/vfio
• /dev/vfio/
• vfio-pci
• vfio_pci
• vfio_pci_core_close_device
• vfio_pci_core_disable
• vfio_pci_dma_buf_cleanup
• dma-buf
• DMABUF
• IOMMU fault
• IO_PAGE_FAULT
• AMD-Vi: Event logged [IO_PAGE_FAULT
• DMAR: [DMA Read]
• DMAR: [DMA Write]
• BAR access
• Memory Space Enable
• device reset
• driver rebind

What your security team should do

• Inventory Linux systems that load vfio-pci or expose /dev/vfio devices, especially virtualization hosts, GPU passthrough systems, accelerator platforms, and multi-tenant compute nodes.
• Prioritize patching systems where untrusted users or workloads can access VFIO devices, even though EPSS is low and the issue is not currently in KEV.
• Upgrade to a vendor-fixed kernel and reboot affected systems into the patched kernel.
• Restrict VFIO access using least privilege: review udev rules, group memberships, container device mounts, device cgroups, and hypervisor passthrough permissions.
• Temporarily disable unnecessary PCI passthrough or DMA-BUF sharing for untrusted workloads until patching is complete.
• Monitor kernel logs for vfio-pci errors, IOMMU faults, device reset storms, unexpected driver rebinds, and crashes during device teardown.
• For custom kernels, backport the upstream vfio/pci cleanup-ordering fix and validate with regression tests around device close, reset, and reassignment.
• Document affected host classes and ensure golden images, hypervisor hosts, and bare-metal provisioning pipelines consume the fixed kernel.