CVE-2026-53283

What it actually does

The flaw is an out-of-bounds read in the Linux kernel AMD IOMMU device lookup path. During PCI/IOMMU initialization, the kernel computes a PCI device identifier and indexes the AMD IOMMU reverse-lookup table before confirming that the identifier is within the table bounds. If a PCI device is present whose BDF is not covered by the IVRS/IOMMU description, the kernel may read adjacent slab memory and treat that data as a struct amd_iommu pointer. In observed cases this causes a general protection fault during boot, resulting in a denial of service. Practical exploitation requires influence over the platform’s PCI/firmware/virtual hardware presentation rather than ordinary network access.

Why it matters to the business

Affected systems can fail to boot or crash during early kernel initialization when specific AMD IOMMU and PCI topology conditions are present. The most likely operational impact is service outage for Linux hosts or virtual machines after deploying an affected kernel, especially in virtualized or cloud environments where firmware tables and virtual PCI devices may not align. EPSS is very low, it is not in CISA KEV, and there is no public exploit maturity indicated, so urgency is primarily driven by exposure to AMD IOMMU-enabled systems and kernel rollout risk rather than active mass exploitation.

How an attack unfolds

An attacker or operator with control over virtual hardware, firmware tables, ACPI IVRS contents, or PCI device presentation can create a mismatch where a PCI device exists at a BDF value outside the range described by the AMD IOMMU IVRS data. During boot, the kernel registers the IOMMU and walks PCI devices. For each device, the AMD IOMMU probe path attempts to look up the owning IOMMU using the computed device identifier. Because the reverse-lookup helper does not validate the identifier before indexing the table, the lookup reads beyond the allocated table. The resulting adjacent memory is interpreted as an IOMMU structure pointer and dereferenced, commonly causing a boot-time general protection fault. In most realistic scenarios this is a denial-of-service condition caused by malicious or malformed platform configuration, not a remotely exploitable application-layer vulnerability.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix adding a bounds check in __rlookup_amd_iommu() before indexing the AMD IOMMU reverse-lookup table. If exact vendor fixed versions are not available, obtain the latest kernel security update from the operating system, distribution, cloud image, or appliance vendor. For systems that cannot be immediately patched, mitigations may include avoiding affected kernel versions, booting a known-good previous kernel, disabling AMD IOMMU only where operationally safe and acceptable, or correcting virtual hardware/firmware/IVRS configuration so all exposed PCI devices are properly described. Validate mitigation carefully because disabling IOMMU can reduce DMA isolation and may affect virtualization, passthrough, and device security features.

How to confirm the fix worked

Confirm the running kernel includes the fix from the vendor or upstream stable branch. Reboot affected hardware or VM profiles after patching and verify that PCI/IOMMU initialization completes without a general protection fault. Review boot logs for successful AMD IOMMU initialization and absence of crashes in amd_iommu_probe_device, __iommu_probe_device, iommu_device_register, amd_iommu_init, or pci_iommu_init. On virtualized platforms, compare PCI devices exposed to the guest with firmware/IVRS descriptions to ensure the topology is consistent. Where kernel package metadata is available, verify the installed kernel version is at or above the distribution’s fixed release.

Typical attack path

1. Gain the ability to influence platform hardware description, hypervisor device model, firmware/ACPI IVRS data, or PCI device exposure.
2. Present a PCI device whose BDF is not represented within the AMD IOMMU IVRS-described lookup range.
3. Boot an affected Linux kernel with AMD IOMMU initialization enabled.
4. Allow kernel PCI/IOMMU initialization to enumerate the malformed or mismatched device topology.
5. Trigger an out-of-bounds reverse-lookup table access in the AMD IOMMU driver.
6. Cause a kernel general protection fault during boot, preventing the system or VM from starting normally.

How to detect it

This issue is primarily detected through boot-time failure evidence rather than post-compromise artifacts. Review kernel ring buffers, persistent journal logs, serial console output, hypervisor console logs, crash dumps, and remote management console logs for general protection faults during early boot involving AMD IOMMU initialization. Key artifacts include stack traces referencing amd_iommu_probe_device, __iommu_probe_device, iommu_device_register, amd_iommu_init, pci_iommu_init, or messages showing PCI devices being added to IOMMU groups immediately before an Oops. Because successful exploitation normally results in a crash before normal services start, also check failed boot records, watchdog resets, crashkernel/kdump outputs, and cloud instance serial console logs. There are no reliable network indicators for this vulnerability, and evidence of exploitation will usually appear as a kernel boot crash correlated with malformed or mismatched PCI/IVRS device topology.

• Oops: general protection fault
• probably for non-canonical address
• RIP: 0010:amd_iommu_probe_device
• amd_iommu_probe_device+0x54/0x3a0
• __iommu_probe_device
• probe_iommu_group
• bus_for_each_dev
• iommu_device_register
• iommu_go_to_state
• amd_iommu_init
• pci_iommu_init
• Adding to iommu group
• gVNIC at 00:08.0
• devid 0x40
• IVRS
• rlookup_table

What your security team should do

• Inventory Linux systems running affected kernel builds on AMD IOMMU-enabled hosts or VM types, prioritizing systems that recently adopted kernels around the affected AMD IOMMU changes.
• Apply vendor kernel updates or move to a fixed kernel as part of normal emergency change processes for systems that fail to boot or that rely on virtualized PCI device presentation.
• For cloud or hypervisor-managed environments, validate VM instance families and images against provider advisories, especially where unusual PCI devices or accelerator endpoints are exposed.
• Retain at least one known-good bootable kernel entry during rollout so systems can recover if the affected kernel crashes during initialization.
• Monitor boot, console, kernel, and crash logs for AMD IOMMU general protection faults after kernel upgrades.
• Do not rely on disabling IOMMU as a broad workaround unless the security and operational consequences have been reviewed.