CVE-2026-53280

What it actually does

This is a Linux kernel denial-of-service flaw in the IOMMU PCI device reset path. If an IOMMU group has no domain because default domain allocation failed during initial device probing, pci_dev_reset_iommu_done() can still attempt to reattach the device and invoke __iommu_attach_device(), which dereferences domain->ops->attach_dev. Because the domain pointer may be NULL, the kernel can trigger a NULL pointer dereference and crash or oops the system. The impact is availability loss rather than code execution based on the available description.

Why it matters to the business

Successful exploitation can crash affected Linux systems, interrupting workloads, virtualized infrastructure, storage/network devices, or hosts that rely on PCI passthrough, IOMMU, VFIO, SR-IOV, or hotplug/reset workflows. The current public exploit maturity is listed as none, EPSS is very low, and it is not in CISA KEV or known ransomware use, so urgency is lower than actively exploited vulnerabilities; however, systems with untrusted local users, device passthrough, or frequent PCI device reset operations should still prioritize kernel updates because a local crash can cause service outages.

How an attack unfolds

An attacker needs a way to influence or trigger PCI device reset activity on an affected Linux kernel while the relevant IOMMU group is in a state where its default domain was not allocated successfully. In a practical scenario, this is most likely to involve local access, administrative-equivalent device management capabilities, access to exposed VFIO/passthrough workflows, or a privileged container/virtualization management path that can cause PCI reset or reprobe behavior. When pci_dev_reset_iommu_done() runs after reset, it may assume group->domain is valid and attempt to reattach the device. The reattach path dereferences the NULL domain pointer, causing a kernel oops or panic depending on kernel panic-on-oops configuration, resulting in denial of service.

How to fix it

Update the Linux kernel to a version that includes the fix for the IOMMU pci_dev_reset_iommu_done() NULL domain dereference. The fix skips the reattach operation when group->domain is NULL. Because no specific affected product list or fixed package versions were provided, obtain the corrected kernel from the relevant Linux distribution, appliance vendor, cloud image provider, or upstream stable kernel branch. As interim mitigation, restrict local users and automation from triggering PCI reset, VFIO assignment changes, SR-IOV reconfiguration, hotplug/reprobe operations, and other device-management actions unless required. Limit access to /sys/bus/pci device reset interfaces and virtualization/device-passthrough management tooling to trusted administrators only. Consider disabling unnecessary PCI passthrough/VFIO/SR-IOV functionality on exposed multi-user systems until patched.

How to confirm the fix worked

Confirm the running kernel build includes the upstream fix or the distribution/vendor backport for this issue. Validate by checking vendor advisories, kernel changelogs, and package metadata for the IOMMU change that skips reattach in pci_dev_reset_iommu_done() when group->domain is NULL. After patching, reboot into the updated kernel and verify with uname -a and package-manager queries that the active kernel is the fixed version, not merely installed. Where safe and appropriate in a test environment, exercise PCI reset or VFIO/passthrough workflows that previously could trigger the issue and confirm there are no kernel oops, panic, or NULL pointer dereference messages in dmesg or the system journal.

Typical attack path

1. Obtain local access or access to a management path capable of triggering PCI device reset, reprobe, passthrough, VFIO, SR-IOV, or hotplug-related operations.
2. Target a system using the Linux IOMMU subsystem where default domain allocation can fail or has failed for a PCI device group.
3. Trigger the PCI reset completion path so pci_dev_reset_iommu_done() attempts to reattach the device.
4. Cause __iommu_attach_device() to dereference a NULL group->domain pointer through domain->ops->attach_dev.
5. Induce a kernel oops, panic, or host crash, disrupting services running on the system.

How to detect it

Look for evidence of kernel crashes, oops events, or panics around PCI reset, IOMMU attach, VFIO, SR-IOV, or device reprobe operations. Primary log sources include dmesg, /var/log/kern.log, /var/log/messages, systemd journal, crash dump directories such as /var/crash, kdump/vmcore repositories, hypervisor management logs, and virtualization orchestration audit logs. Search for stack traces containing pci_dev_reset_iommu_done(), __iommu_attach_device(), iommu_attach_device, NULL pointer dereference, and domain->ops or attach_dev references. Correlate crash timestamps with administrative or user-triggered PCI reset events, writes to sysfs PCI reset files, VFIO device attach/detach operations, SR-IOV VF enablement changes, VM start/stop events using PCI passthrough, or kernel messages indicating default IOMMU domain allocation failure. Because the vulnerability causes denial of service rather than leaving a durable payload, exploitation evidence is most likely to be crash artifacts and triggering activity rather than malware files or network indicators.

• pci_dev_reset_iommu_done
• __iommu_attach_device
• iommu_attach_device
• NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops: 0000
• domain->ops->attach_dev
• attach_dev
• IOMMU
• iommu:
• default domain
• failed to allocate default domain
• /sys/bus/pci/devices/*/reset
• /var/crash
• vmcore
• kdump

What your security team should do

• Inventory Linux systems using IOMMU, VFIO, PCI passthrough, SR-IOV, hotplug-capable PCI devices, or virtualization hosts, and prioritize them for kernel update validation.
• Apply vendor-provided kernel updates or stable kernel releases containing the pci_dev_reset_iommu_done() NULL-domain fix, then reboot into the fixed kernel.
• Restrict access to PCI reset and device-management interfaces, including sysfs reset controls and virtualization platforms that expose device passthrough operations.
• Review recent kernel logs for NULL pointer dereferences involving pci_dev_reset_iommu_done(), __iommu_attach_device(), IOMMU, or PCI reset paths to identify possible prior crashes.
• For high-availability infrastructure, schedule rolling reboots and confirm failover capacity before patching, since kernel updates require reboot to take effect.
• Track distribution advisories because fixed versions are package- and vendor-specific and were not provided in the input.
• Given low EPSS, no KEV listing, no ransomware association, and no public exploit maturity, treat this as important for exposed multi-user or virtualization hosts but not as an internet-scale emergency.