Linux amdkfd: missing bounds check on the CRIU-supplied SDMA queue id

CVSS 7.8CVE-2026-97497NVIDIA / GPU stackcurated

Impact

allocate_sdma_queue accepts a caller-specified SDMA queue id - the path CRIU uses to restore checkpointed GPU processes - without checking it against the maximum queue count, so an out-of-range id indexes past the driver's queue bitmap and arrays. Any process that can open /dev/kfd on an AMD GPU node can pass that id directly, making this an unauthenticated-within-the-node write outside the intended bounds in the kernel. On a multi-tenant ROCm host that is a local privilege-escalation and node-crash primitive available to ordinary GPU tenants. It is separate from the destroy-queue race in the same driver (CVE-2026-97429) - different code path, different fix.

Who can reach it

Local user holding /dev/kfd on an AMD GPU node; reached through the KFD queue-creation ioctl with a restore id, no elevated privilege required.

What to do

Pick up the stable-tree amdkfd bounds-check commit and reboot each AMD GPU node after installing the kernel. Interim mitigation is to withhold /dev/kfd from untrusted workloads, which also disables ROCm for them. Combine the maintenance window with the other amdkfd fix in this batch.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-97497 https://git.kernel.org/stable/c/42f2bd50236b61ad0aeb2c233c990ee0d615fdad https://git.kernel.org/stable/c/dd2870ca036e1d51baa59f942007b36a595b5890

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.