CVE-2026-52952

What it actually does

This is a Linux kernel use-after-free condition in the IOMMU group domain handling path. During device reset and recovery, the kernel may reject some concurrent domain attachment operations while still allowing teardown paths to proceed in a way that leaves group->domain pointing to a domain object that is being freed. A subsequent re-attach path, such as pci_dev_reset_iommu_done(), can dereference the stale domain pointer. The most likely technical outcome is a kernel warning, crash, or denial of service; depending on hardware, IOMMU configuration, allocator behavior, and attacker control over timing, kernel memory corruption or privilege escalation may be theoretically possible, but no public exploit maturity is indicated.

Why it matters to the business

Systems that rely on affected Linux kernel versions and IOMMU features, especially virtualization hosts, PCI passthrough environments, SR-IOV deployments, or systems that frequently reset PCI devices, may be exposed to host instability or crashes. In operational terms, exploitation or accidental triggering could interrupt workloads, disrupt virtual machines or device-backed services, and require emergency host reboots. The EPSS score is very low, it is not listed in CISA KEV, and no ransomware use is indicated, so broad internet-scale exploitation is not currently expected; however, kernel-level issues should still be remediated through standard kernel update cycles, particularly on shared or multi-tenant compute infrastructure.

How an attack unfolds

An attacker would need a way to influence or trigger IOMMU-related device reset, detach, or domain reattachment behavior on a vulnerable Linux system. In a realistic scenario, this is most relevant where an untrusted or lower-privileged party can interact with PCI devices through passthrough, VFIO, SR-IOV, device assignment, or administrative device reset workflows. The attacker attempts to race or repeatedly trigger reset/recovery paths while IOMMU group domain teardown or no-fail domain assignment paths are executing. If the vulnerable ordering occurs, the kernel may leave an IOMMU group pointing at a domain object that has already been freed. A later reattachment path can reuse that stale pointer, causing a use-after-free. The immediate result may be a kernel WARN, oops, panic, or host denial of service. More advanced exploitation would require shaping kernel heap reuse after the freed IOMMU domain object, which is highly environment-specific and not known to be publicly weaponized for this CVE.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the IOMMU group domain reset handling issue. Because no specific affected product list or fixed package versions were provided, use the kernel packages supplied by the relevant Linux distribution, appliance vendor, cloud image provider, or hardware platform vendor, and confirm that the vendor advisory references this CVE or the corresponding upstream IOMMU fix. Prioritize virtualization hosts, systems using PCI passthrough/VFIO, SR-IOV-enabled hosts, bare-metal platforms with frequent PCI device resets, and systems where untrusted users can influence device assignment. If immediate patching is not possible, reduce exposure by limiting access to device reset interfaces, VFIO and PCI passthrough configuration, SR-IOV management, and administrative operations that detach or reattach PCI devices; avoid assigning physical devices to untrusted guests where feasible; and schedule controlled maintenance windows to reduce unplanned crash impact.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version and matching it against the vendor-fixed kernel release for this issue. Reboot into the updated kernel where required, because installing a kernel package alone does not protect a system still running the old kernel. Review vendor changelogs or package metadata for references to the IOMMU reset/domain fix, this CVE, or changes around __iommu_group_set_domain_nofail(), __iommu_group_set_domain_internal(), and recovery_cnt handling. On systems where testing is safe, validate that normal PCI reset, VFIO attach/detach, SR-IOV, and passthrough workflows complete without kernel WARN, oops, or panic messages. Confirm that untrusted users and guests do not have unnecessary access to host-level PCI reset or device assignment controls.

Typical attack path

1. Identify a Linux host running a vulnerable kernel with IOMMU enabled and PCI device reset or device assignment functionality in use.
2. Obtain local, container-adjacent, VM-adjacent, or administrative access capable of influencing PCI reset, VFIO, SR-IOV, or IOMMU device lifecycle operations.
3. Trigger repeated or carefully timed device reset/recovery and domain attach/detach activity for devices in an IOMMU group.
4. Race IOMMU teardown or no-fail domain assignment paths so the group domain pointer can reference a freed domain object.
5. Cause the stale domain pointer to be reused during device reattachment, potentially producing a kernel warning, oops, panic, or memory corruption.
6. Leverage the resulting condition for denial of service, or, if further primitives are developed, attempt kernel-level code execution or privilege escalation.

How to detect it

Look for evidence of attempted or accidental triggering in kernel logs, hypervisor host logs, and system journals. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore artifacts, hypervisor management logs, and automation logs that perform PCI reset, VFIO binding, SR-IOV configuration, or device passthrough changes. Focus on kernel WARN_ON, oops, panic, general protection fault, KASAN use-after-free, or slab corruption messages occurring near IOMMU, PCI reset, VFIO, or device assignment activity. Correlate events with guest lifecycle operations, passthrough attach/detach actions, SR-IOV virtual function resets, hotplug events, and administrative commands that write to PCI reset or driver bind/unbind sysfs interfaces. There are no known public attacker-specific indicators, network signatures, malware artifacts, or threat actor tradecraft tied to this issue; detection is primarily behavioral and crash-forensic.

• __iommu_group_set_domain_nofail
• __iommu_group_set_domain_internal
• pci_dev_reset_iommu_done
• __iommu_group_set_core_domain
• __iommu_release_dma_ownership
• IOMMU_SET_DOMAIN_MUST_SUCCEED
• group->recovery_cnt
• group->domain
• gdev->blocked
• kernel: WARNING
• kernel: WARN_ON
• kernel: BUG: KASAN: use-after-free
• kernel: general protection fault
• kernel: Oops
• kernel panic
• iommu
• vfio-pci
• /sys/bus/pci/devices/*/reset
• /sys/bus/pci/drivers/*/bind
• /sys/bus/pci/drivers/*/unbind

What your security team should do

• Prioritize patching Linux virtualization hosts, PCI passthrough hosts, SR-IOV infrastructure, and systems with IOMMU-enabled device assignment before general-purpose low-risk servers.
• Inventory kernels in use and identify systems where IOMMU, VFIO, PCI passthrough, SR-IOV, or frequent PCI device resets are enabled.
• Apply vendor-provided fixed kernel updates and reboot systems into the patched kernel during the next appropriate maintenance window.
• Restrict administrative access to PCI reset, VFIO, and device assignment operations until patching is complete.
• Monitor kernel logs for IOMMU, PCI reset, WARN_ON, use-after-free, oops, panic, or KASAN reports involving IOMMU group domain handling.
• For shared compute or virtualization platforms, treat unexplained host crashes during device reset or VM device assignment operations as potentially security-relevant until investigated.
• Because this issue is not in CISA KEV, has no known ransomware association, and has low EPSS, handle it as a targeted infrastructure-hardening priority rather than an emergency internet-facing exploitation event.