PT-2026-52922 · Undefined · Undefined
Published
2026-06-26
·
Updated
2026-06-26
·
CVE-2026-53283
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Undefined