GPU VulnDB

Database/NVIDIA / GPU stack

Linux amdkfd: unchecked CRAT subtype length causes out-of-bounds reads when parsing GPU topology

CVSS 8.0CVE-2026-80747NVIDIA / GPU stackcurated

Impact

The KFD compute driver builds the AMD GPU topology that ROCm depends on by walking CRAT tables. It checked that the subtype header fits inside the image but never that the advertised subtype length does, so kfd_parse_subtype() casts the header to larger subtype structs and reads past the end of the image. The consequence is kernel memory read into topology structures, or a fault during driver probe that leaves the node without working amdkfd - meaning no ROCm jobs on that node until it is rebooted. Note what the CRAT table actually is: on a bare-metal AMD GPU node it comes from platform firmware or the adapter, not from a tenant, so this is a firmware-input parsing hardening fix rather than a path a GPU pod can reach.

Who can reach it

Local, and the malformed CRAT table has to come from a source at least as privileged as platform firmware or the adapter itself - the record does not describe a tenant-reachable path. Configurations where guest-supplied ACPI tables reach an amdkfd instance are the case worth checking; a normal process holding /dev/kfd does not supply this input.

What to do

Take the stable kernel update carrying commit 6e7566b or ca91e0c and reboot each AMD GPU node. amdkfd cannot be unloaded while ROCm workloads hold /dev/kfd, so this is a drain-and-reboot per node, not a live patch. The record names no fixed release version, only the stable commits. Given the input source, this is reasonable to fold into the next scheduled kernel maintenance rather than an emergency window.

References

Related entries

All NVIDIA / GPU stack entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.