CVE-2026-53283: AMD IOMMU Kernel Panic – Bounds Check Memory Read Vulnerability

Technical summary

The vulnerability exists in __rlookup_amd_iommu() within the AMD IOMMU driver. The function indexes a kvalloc()-allocated rlookup_table array with a device ID (devid) without bounds-checking, while the caller (check_device()) only validates devid <= pci_seg->last_bdf after the lookup occurs. Prior to commit e874c666b15b, the table was page-aligned, making out-of-bounds reads return NULL safely. After that commit, tight kvcalloc() allocation means the over-read retrieves adjacent slab memory containing arbitrary kernel data. When that data is dereferenced as a struct amd_iommu pointer, a general protection fault occurs. The fix adds bounds validation in __rlookup_amd_iommu() before array access, allowing PCI devices outside the IOMMU's configuration to be safely skipped rather than crashing the kernel.

Business impact

This vulnerability causes denial of service via uncontrolled kernel crash during system boot on affected AMD IOMMU-based platforms. Virtual machine environments and cloud instances with partial or restrictive IOMMU configurations—such as Google Compute Engine VMs with TPU endpoints—are at risk. Systems fail to complete initialization, rendering them unavailable until patched. There is no data confidentiality or integrity impact; the issue is purely availability-focused. Organizations running such infrastructure face service disruptions if systems are restarted or undergo kernel updates that introduce or expose the vulnerability.

Affected systems

The vulnerability affects the Linux kernel across multiple versions where AMD IOMMU support is compiled and the rlookup_table uses kvalloc() allocation (post-commit e874c666b15b). This includes kernel versions 6.18.22 and likely adjacent stable branches. The vulnerability is most readily triggered on virtualized AMD systems with incomplete or restrictive IOMMU device descriptions—particularly common in cloud environments like Google Compute Engine and other hypervisors that present a limited set of IOMMU-managed devices. Bare-metal systems with complete IOMMU BIOS configurations are less likely to be affected, as they typically enumerate all PCI devices in the IVRS. AMD IOMMU support is optional and must be enabled in the kernel configuration to be vulnerable.

Exploitability

The vulnerability is triggered passively during kernel boot when PCI device enumeration occurs, requiring no special privileges or user interaction beyond system restart or kernel initialization. However, exploitability is environment-dependent: it requires a mismatch between the system's actual PCI topology and the IOMMU's configured device descriptors (IVRS). This scenario is most common in virtualized environments where the hypervisor presents a restricted device set. Attackers cannot directly trigger exploitation from user space; it is entirely dependent on system firmware configuration and kernel code paths. The crash occurs early in boot, before user-space execution, limiting post-compromise scenarios.

Remediation

Apply a kernel patch that adds bounds validation in __rlookup_amd_iommu() to check devid against the allocation size before indexing the rlookup_table array. Verify the fix against your vendor's advisory to confirm the exact patch level. For immediate mitigation, disable AMD IOMMU support in the kernel configuration (CONFIG_AMD_IOMMU=n) if operationally feasible, or update to a patched kernel version once available. Organizations should prioritize patching systems in virtualized environments where IOMMU device enumeration mismatches are common.

Patch guidance

Monitor your Linux distribution's security advisories for kernel updates addressing CVE-2026-53283. Patches should be available via your standard kernel update mechanism (e.g., apt, yum, zypper). Test patched kernels in a staging environment before production deployment to ensure compatibility with your AMD IOMMU configuration and any custom kernel modules. If using custom kernel builds, apply the bounds-checking fix directly to __rlookup_amd_iommu() in the iommu/amd driver code and recompile. Verify that systems boot successfully and that IOMMU device enumeration completes without GPF errors.

Detection guidance

Review kernel logs (dmesg, journalctl) for general protection faults (GPF) during boot with stack traces mentioning amd_iommu_probe_device() or __rlookup_amd_iommu(). Boot failures attributed to IOMMU initialization on AMD systems may indicate exposure. Inspect your system's IVRS (IOMMU Virtualization Reporting Structure) via ACPI tables to identify whether PCI devices present in the system are described in the IOMMU configuration. Mismatches between actual PCI topology and IVRS descriptors indicate vulnerability conditions. Systems in virtualized environments (particularly Google Compute Engine or similar hypervisors) with TPU or specialized device configurations should be reviewed proactively.

Why prioritize this

Although the CVSS score is MEDIUM (5.5), prioritization should reflect the practical impact: kernel boot failures prevent system availability entirely. This is a denial-of-service vulnerability affecting critical infrastructure services in virtualized environments. While user-space exploitation is impossible, the boot-time crash means affected systems are inoperable until patched. Cloud and virtualized deployments should be patched urgently; bare-metal systems with complete IOMMU configurations may have lower risk. The environmental dependency (partial IOMMU configuration) should inform prioritization—systems where such configurations are known should be treated as high priority.

Risk score, explained

The CVSS 3.1 score of 5.5 (MEDIUM) reflects the local-only attack vector, low attack complexity, and denial-of-service impact limited to availability. However, this score underrepresents the practical criticality of a boot-time kernel crash affecting virtualized infrastructure. The score does not account for the environmental specificity (which actually narrows the affected population) or the complete unavailability of affected systems once triggered. For risk prioritization, organizations should factor in their deployment environment: virtualized systems with restrictive IOMMU configurations warrant urgent patching despite the MEDIUM label.

Frequently asked questions