CVE-2026-53322: VFIO PCI DMABUF Race Condition Vulnerability in Linux Kernel

Technical summary

The vulnerability exists in vfio_pci_core_close_device() within the VFIO PCI core module. During device closure, the function disables the PCIe function (via vfio_pci_core_disable()) before cleaning up DMABUF mappings. This inverts the correct order of operations. Because DMABUF handles retain access to device BARs (Base Address Registers) independently of the function's MSE state, a race condition occurs: the function's MSE bit is cleared, theoretically revoking access, but active DMABUFs can still read and write device memory until those mappings are explicitly torn down. An attacker with local access and VFIO permissions can exploit this window to access or corrupt device memory. The fix reorders cleanup to call vfio_pci_dma_buf_cleanup() before vfio_pci_core_disable(), ensuring all DMABUF access is revoked before BARs become inaccessible and resources are deallocated.

Business impact

This vulnerability primarily affects systems running virtualization or bare-metal containerized environments that expose PCIe devices via VFIO with DMABUF support (such as GPU passthrough, SR-IOV, or direct device assignment). On affected systems, a local user with VFIO device permissions (typically confined to privileged or specialized containers) can extract sensitive data from device memory, corrupt device state, or cause denial of service. In shared hosting, multi-tenant cloud, or HPC environments, this could enable lateral movement or cross-tenant data leakage. The attack requires local code execution and VFIO permissions, limiting exposure to high-security environments with fine-grained device sharing, but the severity is high because the impact touches confidentiality, integrity, and availability.

Affected systems

The Linux kernel VFIO PCI driver on systems running versions that contain the vulnerable code path. This includes any recent Linux distribution kernel that supports VFIO with DMABUF mappings enabled. Typical affected environments include KVM/QEMU hypervisors with GPU passthrough, Kubernetes clusters using VFIO device plugins, bare-metal container runtimes with device assignment, and research or scientific computing platforms that pass through accelerators. Systems without VFIO enabled, or older kernels predating DMABUF support in VFIO, are not affected. The impact is localized to the kernel version; userspace VFIO library versions are not directly vulnerable, though they may trigger the vulnerable code path.

Exploitability

Exploitation requires local code execution and the ability to open and map a VFIO device via DMABUF, a capability typically restricted to the root user, privileged containers, or specialized device-access groups. The vulnerability is not remotely exploitable. The race condition window is narrow and timing-dependent, making reliable exploitation non-trivial but feasible with a tight loop that holds DMABUF references during device closure. No public exploit code is known at the time of this analysis. The vulnerability is considered high risk because the prerequisites (local access + VFIO permissions) are common in hypervisor and container environments, and the impact (memory access bypass) is severe.

Remediation

Apply the upstream Linux kernel patch that reorders vfio_pci_core_close_device() to clean up DMABUFs before disabling the function. This is a small, surgical fix that eliminates the race condition by ensuring sequential completion: DMABUF cleanup → function disable → resource deallocation. Verify against the vendor advisory for the specific kernel version or distribution you are running. If a patched kernel is unavailable, mitigations include restricting VFIO device access to trusted processes, disabling DMABUF support if not required, or running untrusted workloads in unprivileged namespaces without device-access permissions.

Patch guidance

Check your Linux distribution's advisory for a backported patch or updated kernel package. Upstream fix is available in current kernel development branches. Apply patches to all hypervisors, container hosts, and bare-metal systems that expose VFIO devices. Test GPU passthrough, device assignment, and container device-plugin functionality after patching to confirm proper device cleanup and no performance regressions. For production environments, coordinate patching during scheduled maintenance windows since kernel updates typically require a reboot. Prioritize systems running GPU workloads, HPC clusters, or multi-tenant device-sharing deployments.

Detection guidance

Monitor kernel logs for unexpected VFIO device state warnings or race condition artifacts (e.g., MSE already cleared, lingering BAR access, or resource allocation failures during device closure). Use kernel-space tracing (perf, ftrace) to profile the timing between vfio_pci_core_disable() and DMABUF cleanup calls during device hot-remove or VM shutdown. In user space, monitor VFIO device file descriptor lifecycle and DMABUF mmap/unmap sequences for anomalies. Look for processes that hold DMABUF references across device disable events. On container platforms, audit VFIO device plugin logs for device-access anomalies. Runtime detection of active exploitation is difficult; focus on preventive patching and access control audits.

Why prioritize this

This is a HIGH priority vulnerability because it affects a core kernel subsystem (VFIO PCI) used in virtualization and containerization, has a high CVSS score (8.8), and impacts confidentiality, integrity, and availability. Although exploitation requires local access and specific permissions, those conditions are routine in hypervisor and enterprise container environments. The race condition is real and reproducible under load. It has not yet been added to the KEV catalog, but organizations running GPU passthrough, device assignment, or multi-tenant VFIO workloads should patch urgently. Delay increases risk of data exfiltration or cross-tenant compromise.

Risk score, explained

CVSS 8.8 (HIGH) reflects: Attack Vector Local (user must have code execution on the host), Access Complexity Low (race condition is triggered by normal device shutdown), Privileges Required Low (VFIO device access is often granted to containers or unprivileged user namespaces), User Interaction None (no user action needed beyond device closure), Scope Changed (compromise of one user or container can affect other tenants or the host kernel), and impact on Confidentiality, Integrity, and Availability (all HIGH). The score accurately captures the severity in multi-tenant and shared-device environments. In single-user or air-gapped systems without device sharing, practical risk is lower but the vulnerability remains serious.

Frequently asked questions