CVE-2026-53283

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/amd: Bounds-check devid in __rlookup_amd_iommu()<br /> <br /> iommu_device_register() walks every device on the PCI bus via<br /> bus_for_each_dev() and calls amd_iommu_probe_device() for each. The<br /> inlined check_device() path computes the device&amp;#39;s sbdf, calls<br /> rlookup_amd_iommu() to find the owning IOMMU, and only afterwards<br /> verifies devid last_bdf. __rlookup_amd_iommu() indexes<br /> rlookup_table[devid] with no bounds check of its own, so for a PCI<br /> device whose BDF is not described by the IVRS, the lookup reads past<br /> the end of the allocation before the caller&amp;#39;s bounds check can run.<br /> <br /> This was harmless before commit e874c666b15b ("iommu/amd: Change<br /> rlookup, irq_lookup, and alias to use kvalloc()"): the table was a<br /> zeroed page-order allocation, so the over-read returned NULL and the<br /> caller&amp;#39;s NULL check skipped the device. After that commit the table is<br /> a tight kvcalloc() and the over-read returns adjacent slab contents,<br /> which check_device() then dereferences as a struct amd_iommu *,<br /> causing a boot-time GPF.<br /> <br /> Seen on Google Compute Engine ct6e VMs, where the virtualized IVRS<br /> describes only the four TPU endpoints 00:04.0-07.0; the gVNIC at<br /> 00:08.0 (devid 0x40) indexes 56 bytes past the 456-byte allocation,<br /> into the adjacent kmalloc-512 slab object:<br /> <br /> pci 0000:00:04.0: Adding to iommu group 0<br /> pci 0000:00:05.0: Adding to iommu group 1<br /> pci 0000:00:06.0: Adding to iommu group 2<br /> pci 0000:00:07.0: Adding to iommu group 3<br /> Oops: general protection fault, probably for non-canonical address 0x3a64695f78746382: 0000 [#1] SMP NOPTI<br /> CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.22 #1<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/06/2025<br /> RIP: 0010:amd_iommu_probe_device+0x54/0x3a0<br /> Call Trace:<br /> __iommu_probe_device+0x107/0x520<br /> probe_iommu_group+0x29/0x50<br /> bus_for_each_dev+0x7e/0xe0<br /> iommu_device_register+0xc9/0x240<br /> iommu_go_to_state+0x9c0/0x1c60<br /> amd_iommu_init+0x14/0x40<br /> pci_iommu_init+0x16/0x60<br /> do_one_initcall+0x47/0x2f0<br /> <br /> Guard the array access in __rlookup_amd_iommu(). With the fix applied<br /> on 6.18.22, the gVNIC at 00:08.0 is skipped cleanly and the VM boots.