CVE-2026-53283

NONEPre-NVD 0.0
0.0
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • No confirmed exploitation signals yet
CISA-KEV: Not listedEPSS: 0%CVSS: —Exploit: NoneExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

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.

CVSS v3
—
EG Score
0.0(none)
EPSS
6.1%
KEV
Not listed

Published

June 26, 2026

Last Modified

June 30, 2026

References (3)

Vendor Advisories for CVE-2026-53283(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Data Freshness Timeline

(refreshed 12× in last 7d / 20× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-07-06 18:02 UTCGHSA enrichment
  2. 2026-07-06 16:27 UTCEPSS rescore
  3. 2026-07-06 16:27 UTCEPSS rescore
  4. 2026-07-06 02:23 UTCEPSS rescore
  5. 2026-07-06 02:23 UTCEPSS rescore
  6. 2026-07-05 02:31 UTCEPSS rescore
  7. 2026-07-05 02:30 UTCEPSS rescore
  8. 2026-07-04 06:31 UTCEPSS rescore
  9. 2026-07-04 06:31 UTCEPSS rescore
  10. 2026-07-03 11:06 UTCGHSA enrichment
  11. 2026-07-01 15:07 UTCEPSS rescore
  12. 2026-06-30 23:22 UTCEPSS rescore
  13. 2026-06-30 04:21 UTCEG score recompute
  14. 2026-06-30 04:21 UTCGHSA enrichment
  15. 2026-06-29 14:06 UTCEPSS rescore
  16. 2026-06-29 14:06 UTCEPSS rescore
  17. 2026-06-28 04:56 UTCEPSS rescore
  18. 2026-06-28 04:56 UTCEPSS rescore
  19. 2026-06-26 21:38 UTCEG score recompute
  20. 2026-06-26 21:38 UTCGHSA enrichment

Frequently asked(4)

What is CVE-2026-53283?
CVE-2026-53283 is a none vulnerability published on June 26, 2026. In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bounds-check devid in rlookupamdiommu() iommudeviceregister() walks every device on the PCI bus via busforeachdev() and calls amdiommuprobedevice() for each. The inlined check_device() path computes the device's sbdf,…
When was CVE-2026-53283 disclosed?
CVE-2026-53283 was first published in the National Vulnerability Database on June 26, 2026, with the most recent update on June 30, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-53283 actively exploited?
CVE-2026-53283 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 6.1% percentile likelihood of exploitation in the next 30 days — higher percentiles indicate greater predicted risk.
How do I remediate CVE-2026-53283?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-53283, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-53283

Explore →

Is Your Infrastructure Affected by CVE-2026-53283?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.

Start Free Scan →Browse All CVEs