CVE-2026-53053

What it actually does

This Linux kernel flaw affects the AMD IOMMU driver’s handling of PCI DMA aliases. The vulnerable logic can copy Device Table Entry state from the wrong PCI device identifier when cloning DMA-remapping configuration for an alias device. As a result, an alias device may receive incorrect or stale IOMMU translation, isolation, or permission state. In practical terms, the issue can cause incorrect DMA remapping behavior, device malfunction, kernel instability, or weakened device isolation for systems using AMD IOMMU with PCI devices that expose DMA aliases. Exploitation is not known to be public, EPSS is very low, and the issue is not listed in CISA KEV.

Why it matters to the business

The main operational risk is instability or incorrect isolation on Linux systems using AMD IOMMU, particularly hosts with complex PCI topologies, passthrough, virtualization, or devices that use DMA aliases. In the worst case, incorrect DMA isolation can undermine assumptions used to separate devices, virtual machines, or workloads. Because there is no known exploitation, no KEV listing, and a low EPSS score, this should generally be treated as a kernel maintenance and hardening priority rather than an emergency internet-scale threat; however, virtualization hosts, bare-metal cloud nodes, and systems relying on PCI passthrough should prioritize remediation sooner due to higher impact if IOMMU isolation is incorrect.

How an attack unfolds

An attacker would need a pathway to influence or interact with PCI devices, DMA-capable hardware, or a virtualized/passthrough configuration where AMD IOMMU alias handling is exercised. The vulnerable code path is reached when the kernel clones IOMMU device-table state for a PCI device alias. Because the driver may derive the source device identifier from the alias rather than the original device, stale or incorrect DTE state can be propagated. A capable local attacker, malicious device, compromised guest with assigned hardware, or attacker with control over DMA-capable hardware could attempt to trigger device aliasing behavior and exploit incorrect IOMMU mappings to cause denial of service, device misbehavior, or potentially weaken memory isolation. There is currently no public exploit maturity reported and no known named threat actor activity for this vulnerability.

How to fix it

Apply a Linux kernel update that includes the AMD IOMMU fix for clone_alias() using the original PCI device identifier when cloning alias state. If vendor fixed package versions are not available, update to the latest supported kernel from the operating system or appliance vendor once the fix is included. Prioritize systems with AMD processors/chipsets, IOMMU enabled, PCI passthrough, SR-IOV, VFIO, virtualization hosts, bare-metal multi-tenant infrastructure, or DMA-capable add-in devices. Where immediate patching is not possible, reduce exposure by disabling unnecessary PCI passthrough, limiting untrusted access to assigned devices, avoiding attachment of untrusted DMA-capable peripherals, and reviewing whether IOMMU-dependent isolation is required for security boundaries. Disabling IOMMU may avoid this specific code path but can reduce DMA protection and is generally not recommended as a security mitigation unless advised by the vendor for a specific platform.

How to confirm the fix worked

Confirm the running kernel includes the vendor patch for the AMD IOMMU clone_alias() fix. Validate through distribution advisories, kernel changelogs, package metadata, or source inspection showing clone_alias() uses the original PCI device passed through opaque data rather than deriving the source devid from the alias argument. On Linux systems, check the running kernel version with `uname -r` and compare it against the vendor’s fixed kernel release. After patching, reboot into the fixed kernel and verify the active kernel is the updated one. For higher-risk systems, regression-test PCI passthrough, SR-IOV, VFIO, and IOMMU-dependent workloads, and monitor `dmesg`/kernel logs for AMD-Vi or IOMMU faults after the update.

Typical attack path

1. Gain local, physical, or guest-level access to a system using the AMD IOMMU driver with relevant PCI DMA-alias topology.
2. Interact with, attach, or control a DMA-capable PCI device or a guest-assigned passthrough device that causes PCI DMA alias processing.
3. Trigger the vulnerable alias-cloning path in the AMD IOMMU driver.
4. Cause incorrect or stale Device Table Entry state to be copied to an alias device.
5. Use the resulting incorrect DMA-remapping state to induce device faults, kernel instability, denial of service, or potentially bypass expected device isolation depending on system configuration.

How to detect it

There are no reliable public indicators that uniquely identify exploitation of this vulnerability. To assess possible prior exploitation or impact, review kernel logs, hypervisor logs, and hardware-management telemetry for abnormal AMD-Vi/IOMMU events, DMA-remapping faults, PCI device resets, VFIO or passthrough device failures, unexpected guest or host crashes, and device assignment anomalies. Useful sources include `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `journalctl -k`, hypervisor management logs, crash dumps, and device error counters. Focus on systems with AMD IOMMU enabled and PCI passthrough/SR-IOV/VFIO use. Investigate clusters of IOMMU page faults, device table errors, or faults involving aliasing or assigned devices, especially when correlated with untrusted guest activity or recent hardware attachment. Treat these findings as suspicious operational artifacts, not conclusive proof of exploitation, because the vulnerability does not produce a unique log signature.

What your security team should do

• Inventory Linux systems running on AMD platforms with IOMMU enabled, especially virtualization hosts, PCI passthrough hosts, SR-IOV deployments, and systems using VFIO.
• Track operating system and kernel vendor advisories for the patched kernel and schedule updates according to operational criticality.
• Prioritize remediation on systems where IOMMU isolation is part of a security boundary between guests, tenants, workloads, or device assignments.
• Reboot systems after kernel updates and verify the fixed kernel is actually running, not merely installed.
• Until patched, restrict untrusted access to passthrough or DMA-capable devices and avoid attaching untrusted PCI/Thunderbolt-class hardware where applicable.
• Monitor kernel logs for AMD-Vi/IOMMU faults, unexpected PCI device resets, host instability, or passthrough device anomalies, recognizing these are symptoms rather than definitive exploitation indicators.
• Because EPSS is low, exploit maturity is reported as none, and the vulnerability is not in KEV, handle through prioritized patch management rather than emergency incident response unless suspicious device or kernel activity is observed.