Linux kernel amdkfd: unvalidated CRIU-restored IDs reach idr_alloc and can trigger a kernel WARN

UnscoredCVE-2026-80870NVIDIA / GPU stackcurated

Impact

The KFD checkpoint/restore path takes object IDs straight from userspace-supplied CRIU data and passes them to idr_alloc() without bounding them to INT_MAX. A restored ID above INT_MAX trips a WARN in the IDR layer; on a host booted with panic_on_warn that turns into a panic and a reboot. This is the AMD compute driver behind /dev/kfd, so the caller is anyone allowed to run ROCm workloads, and on a shared AMD GPU node one tenant's crafted restore image can take the whole node down with every other tenant's jobs on it. The record describes no memory corruption - Smatch flagged the unchecked userspace value and the fix returns -EINVAL - so treat this as availability, not escalation.

Who can reach it

Local user holding /dev/kfd who can invoke the KFD CRIU restore ioctl with attacker-chosen event and BO IDs. No authentication beyond access to the device node, which any GPU pod on a ROCm node has.

What to do

Pick up the stable commits listed in the record, which add INT_MAX validation before idr_alloc() in both restore paths. The record names no fixed release, only the commit ids. Deployment is a kernel update: drain the node and reboot. Where CRIU-based checkpointing of GPU jobs is not used, denying the restore ioctl or not exposing /dev/kfd to untrusted tenants removes the reachable path in the meantime.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-80870 https://git.kernel.org/stable/c/085ea93bda71fee600cc12a17026598eb10dd1f9 https://git.kernel.org/stable/c/cb6311f25a096621ac7ffd91b50d1bb1cfb63a96

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.