CVE-2026-53281

What it actually does

This is a Linux kernel Intel VT-d IOMMU flaw in PASID/domain teardown handling. When a device PASID entry is not found, the kernel can continue cleanup using a NULL dev_pasid pointer, causing a NULL pointer dereference. In related cases, teardown may decrement a domain reference count even though no valid PASID was removed, potentially corrupting refcount state and allowing premature release of a shared IOMMU domain, which can lead to use-after-free conditions for other active devices. The most likely impact is local kernel crash or instability; under specific device-assignment, PASID, VFIO, iommufd, virtualization, or accelerator-use scenarios, the refcount corruption aspect may have broader memory-safety implications.

Why it matters to the business

Systems using affected Linux kernels with Intel VT-d/IOMMU functionality may experience kernel crashes, host instability, or disruption of workloads that rely on device passthrough, virtualization, accelerators, or shared I/O domains. For organizations running dense virtualization, GPU/accelerator workloads, DPDK, VFIO, or containerized workloads with assigned devices, exploitation or accidental triggering could cause service interruption and workload outages. The current EPSS is very low, it is not listed in CISA KEV, and there is no known public exploit maturity, so this should generally be treated as a patch-cycle stability and defense-in-depth issue unless the environment exposes untrusted users to device assignment or IOMMU management paths.

How an attack unfolds

An attacker would need a way to trigger Intel VT-d IOMMU PASID/domain attach and detach behavior on an affected kernel. In plausible scenarios, this could involve local access to interfaces such as VFIO, iommufd, mediated devices, device passthrough, accelerator frameworks, or other privileged/sub-privileged paths that manipulate IOMMU domains and PASIDs. The attacker attempts to drive teardown for a PASID/domain relationship that was not actually present or was already removed. Because the vulnerable code continues teardown even when the dev_pasid lookup fails, the kernel may dereference NULL and crash. If the teardown path instead reaches refcount handling with inconsistent state, it may decrement a reference count incorrectly, potentially freeing an IOMMU domain still used by other devices and creating a use-after-free condition. In practice, exploitation is expected to be local and highly configuration-dependent, with denial of service being the most likely outcome.

How to fix it

Upgrade to a Linux kernel version or vendor backport that contains the upstream fix for the Intel VT-d IOMMU PASID teardown logic, specifically the change that returns early when dev_pasid is NULL before teardown and refcount operations. Because no product-specific fixed versions were provided, track the advisory from the operating system or appliance vendor and apply the fixed kernel package when available. If immediate patching is not possible, reduce exposure by limiting access to VFIO/iommufd/device-passthrough capabilities, avoiding assignment of PASID-capable devices to untrusted workloads, disabling unnecessary IOMMU-dependent device sharing features, and ensuring only trusted administrators can create or manage virtual machines, accelerators, mediated devices, or passthrough devices. Disabling Intel VT-d/IOMMU may mitigate the vulnerable code path but can break virtualization, DMA isolation, passthrough, and security controls, so it should only be considered as a temporary, risk-assessed workaround.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix or an equivalent backport by checking the installed kernel package changelog/advisory for this CVE or for the Intel VT-d dev_pasid NULL teardown fix. Validate that systems have rebooted into the fixed kernel, since installing kernel packages alone is insufficient. On Linux, compare the running kernel from `uname -r` with the vendor-fixed kernel version and verify package status with the platform package manager. For source-based or custom kernels, confirm the IOMMU VT-d code returns early when dev_pasid lookup fails before teardown/refcount operations. Also verify exposure by checking whether Intel VT-d/IOMMU is enabled, whether VFIO/iommufd/passthrough/accelerator workloads are in use, and whether untrusted users can access relevant device-management interfaces.

Typical attack path

1. Gain local code execution or authorized access to a workload/user context capable of interacting with device assignment, VFIO, iommufd, accelerator, or IOMMU-related kernel interfaces.
2. Identify that the host is running an affected Linux kernel with Intel VT-d/IOMMU enabled and PASID-capable device paths in use.
3. Create, attach, detach, or race device PASID/domain state so that teardown is invoked when the expected dev_pasid entry is absent.
4. Trigger the vulnerable teardown path, causing either a NULL pointer dereference or an incorrect domain reference count decrement.
5. Cause kernel oops/panic, host instability, or potentially corrupt IOMMU domain lifetime state affecting other active devices.

How to detect it

Look for signs of prior triggering in kernel and system logs rather than network telemetry, because this is a local kernel flaw. Primary sources include `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, systemd journal entries from the kernel, crash dumps, kdump/vmcore artifacts, hypervisor management logs, and virtualization/device-assignment audit logs. Search for kernel oops or panic events involving Intel VT-d, DMAR, IOMMU, PASID, domain detach, VFIO, iommufd, refcount warnings, NULL pointer dereferences, or use-after-free/KASAN reports. Correlate crashes with recent attach/detach of passthrough devices, virtual machine lifecycle events, accelerator allocation/deallocation, SR-IOV VF assignment, or workloads using PASID-capable devices. Because there are no public exploit-specific artifacts, detection should focus on abnormal local use of device-assignment interfaces followed by kernel faults in the IOMMU/VT-d subsystem.

• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops: 0000
• Kernel panic - not syncing
• DMAR:
• iommu/vt-d
• Intel-IOMMU
• PASID
• dev_pasid
• refcount_t: underflow
• refcount_t: decrement hit 0
• use-after-free
• KASAN: use-after-free
• vfio
• iommufd
• /dev/vfio/vfio
• /dev/iommu
• /sys/kernel/iommu_groups

What your security team should do

• Prioritize patching affected Linux hosts that use Intel VT-d, VFIO, iommufd, device passthrough, GPUs, accelerators, SR-IOV, or virtualization platforms with assigned devices.
• Apply vendor kernel updates and reboot into the fixed kernel; confirm the running kernel, not just the installed package, is remediated.
• Restrict access to VFIO, iommufd, mediated-device, passthrough, and accelerator-management interfaces to trusted administrators and trusted workloads only.
• Review virtualization and container platforms for untrusted tenant access to device assignment or PASID-capable hardware features.
• Monitor kernel logs for IOMMU, VT-d, PASID, NULL pointer dereference, refcount, use-after-free, oops, and panic events, especially following device attach/detach operations.
• If patching is delayed, consider temporarily disabling or reducing use of high-risk device-passthrough and shared-device workflows on multi-user or multi-tenant systems.
• Track vendor advisories because fixed versions may differ by distribution and may be delivered as a backported patch without changing to a new upstream kernel major version.