Linux Kernel EUVD-2026-39888

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. This last condition is typical of virtualized environments where the hypervisor synthesizes a minimal IVRS covering only IOMMU-managed endpoints. Exploitation is constrained by the purely local-hardware nature: no network reachability, no user credentials, and no attacker-controlled input are involved - the crash is triggered automatically by kernel boot-time PCI enumeration. The impact is limited entirely to availability (system fails to boot); there is no confidentiality or integrity impact confirmed.

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. The EPSS score of 0.17% (6th percentile) reflects the extremely low probability of traditional exploitation - this is a hardware/configuration-triggered regression rather than an attacker-weaponizable flaw. There is no CISA KEV listing and no known public exploit. However, the practical severity in affected environments is higher than the base score implies: the crash occurs during kernel initialization before any user-space process runs, meaning affected VMs simply fail to boot - a complete availability loss. In cloud environments like GCE where virtualized IVRS tables omit non-IOMMU-managed devices, this bug is triggered deterministically on every boot of an affected kernel version. The signal mismatch - modest CVSS but severe operational impact in specific cloud configurations - warrants elevated priority for operators running AMD IOMMU with partial IVRS coverage on kernels 6.16 through 6.18.32 or 7.0.x before 7.0.10. No conflicting data between sources was identified.

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. No attacker input or privileged user action is required; the crash is fully deterministic given the hardware and kernel version combination. No public proof-of-concept code exists.