Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Local vector confirmed; crash triggered at boot by hardware configuration with no confidentiality or integrity impact, only total availability loss.
Primary rating from NVD.
CVSS VectorNVD
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Lifecycle Timeline
5DescriptionNVD
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.
AnalysisAI
Boot-time kernel crash in Linux 6.16+ on AMD IOMMU-equipped systems causes a General Protection Fault when a PCI device whose Bus:Device.Function address is absent from the ACPI IVRS table is encountered during IOMMU initialization. The root cause is a missing bounds check in __rlookup_amd_iommu() that was latent until commit e874c666b15b changed the rlookup_table allocation from a zeroed page-order block (which returned NULL on overrun) to a tight kvcalloc(), causing adjacent slab contents to be dereferenced as a valid struct amd_iommu pointer. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | This vulnerability requires three concurrent conditions: (1) the system must use AMD IOMMU, meaning the CPU and platform must be AMD-based and the kernel must have booted with AMD IOMMU enabled (the default when IVRS is present in ACPI tables); (2) the running kernel must be at or after commit e874c666b15b but before the fix commits, corresponding to versions 6.16 through 6.18.32 or 7.0.x prior to 7.0.10; and (3) at least one PCI device must be present whose BDF (Bus:Device.Function) produces a devid value exceeding the bounds of the rlookup_table, which occurs when the ACPI IVRS table describes fewer devices than the number physically or virtually present. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The NVD CVSS 3.1 score of 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) accurately captures the local-only, availability-only nature of this bug. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | A virtual machine running Linux 6.16 through 6.18.32 on a hypervisor that exposes an AMD IOMMU with a partial IVRS table - such as a Google Compute Engine ct6e instance whose IVRS covers only TPU endpoints 00:04.0-07.0 while a gVNIC adapter sits at 00:08.0 - triggers the bug automatically at boot. During iommu_device_register(), the gVNIC's devid 0x40 indexes 56 bytes past the 456-byte rlookup_table allocation into an adjacent kmalloc-512 slab object, whose contents are dereferenced as a struct amd_iommu pointer, producing a non-canonical address GPF and halting the boot sequence. … |
| Remediation | The primary fix is to upgrade to Linux 6.18.33, 7.0.10, or 7.1 (mainline), which introduce a bounds check in __rlookup_amd_iommu() before indexing rlookup_table[devid]. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
On BIG-IP versions 16.0.x before 16.0.1.1, 15.1.x before 15.1.2.1, 14.1.x before 14.1.4, 13.1.x before 13.1.3.6, and 12.
An exploitable code execution vulnerability exists in the Shader functionality of AMD Radeon DirectX 11 Driver atidxx64.
An exploitable code execution vulnerability exists in the Shader functionality of AMD Radeon DirectX 11 Driver atidxx64.
An exploitable code execution vulnerability exists in the Shader functionality of AMD Radeon DirectX 11 Driver atidxx64.
An exploitable memory corruption vulnerability exists in AMD atidxx64.dll 26.20.15019.19000 graphics driver. Rated criti
plays_service.exe in the plays.tv service before 1.27.7.0, as distributed in AMD driver-installation packages and Gaming
A flaw was found in the KVM's AMD code for supporting SVM nested virtualization. Rated high severity (CVSS 8.8), this vu
AMD ATI atillk64.sys 5.11.9.0 allows low-privileged users to interact directly with physical memory by calling one of se
An exploitable out-of-bounds read vulnerability exists in AMD ATIDXX64.DLL driver, version 26.20.13001.29010. Rated high
AMD fglrx-driver before 15.9 allows local users to gain privileges via a symlink attack. Rated high severity (CVSS 7.8),
AMD fglrx-driver before 15.7 allows local users to gain privileges via a symlink attack. Rated high severity (CVSS 7.8),
A vulnerability, which was classified as critical, has been found in TechPowerUp Ryzen DRAM Calculator 1.2.0.5.sys. Rate
Same weakness CWE-476 – NULL Pointer Dereference
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-39888
GHSA-gv9j-3945-3x3r