CVE-2026-53283
Received Received - Intake
Bounds-check devid in __rlookup_amd_iommu() in Linux Kernel

Publication date: 2026-06-26

Last updated on: 2026-06-26

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bounds-check devid in __rlookup_amd_iommu() iommu_device_register() walks every device on the PCI bus via bus_for_each_dev() and calls amd_iommu_probe_device() for each. The inlined check_device() path computes the device's sbdf, calls rlookup_amd_iommu() to find the owning IOMMU, and only afterwards verifies devid <= pci_seg->last_bdf. __rlookup_amd_iommu() indexes rlookup_table[devid] with no bounds check of its own, so for a PCI device whose BDF is not described by the IVRS, the lookup reads past the end of the allocation before the caller's bounds check can run. This was harmless before commit e874c666b15b ("iommu/amd: Change rlookup, irq_lookup, and alias to use kvalloc()"): the table was a zeroed page-order allocation, so the over-read returned NULL and the caller's NULL check skipped the device. After that commit the table is a tight kvcalloc() and the over-read returns adjacent slab contents, which check_device() then dereferences as a struct amd_iommu *, causing a boot-time GPF. Seen on Google Compute Engine ct6e VMs, where the virtualized IVRS describes only the four TPU endpoints 00:04.0-07.0; the gVNIC at 00:08.0 (devid 0x40) indexes 56 bytes past the 456-byte allocation, into the adjacent kmalloc-512 slab object: pci 0000:00:04.0: Adding to iommu group 0 pci 0000:00:05.0: Adding to iommu group 1 pci 0000:00:06.0: Adding to iommu group 2 pci 0000:00:07.0: Adding to iommu group 3 Oops: general protection fault, probably for non-canonical address 0x3a64695f78746382: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.22 #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/06/2025 RIP: 0010:amd_iommu_probe_device+0x54/0x3a0 Call Trace: __iommu_probe_device+0x107/0x520 probe_iommu_group+0x29/0x50 bus_for_each_dev+0x7e/0xe0 iommu_device_register+0xc9/0x240 iommu_go_to_state+0x9c0/0x1c60 amd_iommu_init+0x14/0x40 pci_iommu_init+0x16/0x60 do_one_initcall+0x47/0x2f0 Guard the array access in __rlookup_amd_iommu(). With the fix applied on 6.18.22, the gVNIC at 00:08.0 is skipped cleanly and the VM boots.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-06-26
Last Modified
2026-06-26
Generated
2026-06-27
AI Q&A
2026-06-26
EPSS Evaluated
N/A
NVD
CVE-2026-53283
EUVD
EUVD-2026-39888
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
amd linux_kernel 6.18.22
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability exists in the Linux kernel's AMD IOMMU code, specifically in the function __rlookup_amd_iommu(). The function indexes an array without performing a proper bounds check on the device ID (devid). When a PCI device's BDF (Bus-Device-Function) is not described by the IVRS, the lookup reads beyond the allocated memory before the caller's bounds check occurs.

Before a certain kernel commit, this was harmless because the table was zeroed and the over-read returned NULL, which was safely handled. After the commit, the table became a tightly allocated memory region, so the over-read returned adjacent memory contents. This caused the kernel to dereference invalid data as a pointer, leading to a general protection fault (GPF) during boot.

The issue was observed on Google Compute Engine VMs where the virtualized IVRS described only certain devices, but a device outside this range caused the out-of-bounds read and subsequent crash.

Impact Analysis

This vulnerability can cause a system crash (general protection fault) during the boot process on affected Linux kernels running on AMD hardware with certain PCI device configurations. Specifically, it can cause the kernel to dereference invalid memory, leading to a boot failure.

For users running virtualized environments like Google Compute Engine VMs, this means that certain devices not properly described in the IVRS can trigger this fault, preventing the VM from booting successfully.

Detection Guidance

This vulnerability manifests as a general protection fault (GPF) during boot time when the Linux kernel attempts to probe PCI devices via amd_iommu_probe_device(). A key indicator is a kernel oops message referencing amd_iommu_probe_device and a general protection fault related to invalid memory access.

To detect this issue, monitor your system's kernel logs (e.g., using dmesg or journalctl) for messages similar to the following pattern:

  • dmesg | grep -i 'amd_iommu_probe_device'
  • journalctl -k | grep -i 'general protection fault'

Additionally, check for PCI devices whose BDF (Bus:Device.Function) is not described by the IVRS table, as these devices may trigger the vulnerability during iommu_device_register().

Mitigation Strategies

The vulnerability is resolved by applying a patch that adds bounds checking in the __rlookup_amd_iommu() function to prevent out-of-bounds array access.

Immediate mitigation steps include:

  • Update your Linux kernel to version 6.18.22 or later, where the fix has been applied.
  • If updating is not immediately possible, avoid using PCI devices whose BDFs are not described by the IVRS, as these trigger the out-of-bounds access.
  • Monitor system boot logs for general protection faults related to amd_iommu_probe_device to identify if the vulnerability is being triggered.
Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-53283. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart