CVE-2026-53283
Beschrijving NL
In de Linux kernel is de volgende kwetsbaarheid verholpen:
iommu/amd: Grenzen-controledevid in __rlookup_amd_iommu()
iommu_device_register() loopt elk apparaat op de PCI-bus via
bus_for_each_dev() en belt amd_iommu_probe_device() voor elk. De
inline check_device() pad berekent de sbdf, oproepen van het apparaat
rlookup_amd_iommu () om de eigenaar van IOMMU te vinden, en pas daarna
verifieert devid last_bdf. __rlookup_amd_iommu() indexen
rlookup_table[devid] zonder eigen grenscontrole, dus voor een PCI
apparaat waarvan de BdF niet wordt beschreven door het IVRS, leest de lookup voorbij
het einde van de toewijzing voordat de grenscontrole van de beller kan worden uitgevoerd. Dit was onschadelijk voor commit e874c666b15b ("iommu/amd: Change
rlookup, irq_lookup en alias om kvalloc () ") te gebruiken: de tabel was een
paginavolgorde-allocatie op nul gezet, zodat de over-lezing NULL en de
nULL check van de beller heeft het apparaat overgeslagen. Daarna wordt de tabel gecommit
een strakke kvcalloc() en de overgelezen retourneert aangrenzende plaatinhoud,
die check_device() vervolgens dereferences als een struct amd_iommu *,
waardoor een opstarttijd GPF ontstaat. Gezien op Google Compute Engine ct6e VMS, waar de gevirtualiseerde IVRS
beschrijft alleen de vier TPU-eindpunten 00:04.0-07.0; de gVNIC op
00:08.0 (devid 0x40) indexeert 56 bytes voorbij de 456-byte toewijzing,
in het aangrenzende kmalloc-512 plaatobject:
pci 0000:00:04.0: Toevoegen aan iommu-groep 0
pci 0000:00:05.0: Toevoegen aan iommu-groep 1
pci 0000:00:06.0: Toevoegen aan iommu-groep 2
pci 0000:00:07.0: Toevoegen aan iommu-groep 3
Oeps: algemene beschermingsfout, waarschijnlijk voor niet-canoniek adres 0x3a64695f78746382: 0000 [#1] SMP NOPTI
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Niet besmet 6.18.22 #1
Hardware naam: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/06/2025
RIP: 0010:amd_iommu_probe_device+0x54/0x3a0
Oproeptracering:
__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
Bewaak de toegang tot de array in __ rlookup_amd_iommu(). Met de fix toegepast
op 6.18.22 wordt de gVNIC om 00:08.0 netjes overgeslagen en wordt de VM opgestart.
Origineel (Engels) tonen
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 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.