The CVE addresses missing bounds validation in the amdkfd driver's CRIU restore path. When restoring a checkpoint, the kernel accepts queue_type and mqd_size values directly from the saved state without verifying they fall within valid ranges before using them to index into internal structures or derive memory sizes. An invalid queue_type value can trigger an out-of-bounds access or NULL dereference (CVSS 7.1).
If you run CRIU to checkpoint and restore AMD GPU workloads, you are in-scope. The restore operation requires privilege, which creates a partial but incomplete trust boundary — the assumption that a privileged CRIU operation implies valid checkpoint data is the exact pattern that failed here. Checkpoint files can become corrupted, be replayed against different kernel versions, or be intentionally malformed. The privilege gate restricts the attacker population but does not eliminate the validation requirement.
Prioritize this patch if your environment uses AMD GPUs with CRIU, particularly in containerized or cloud GPU deployments where checkpoint files may migrate between hosts or be stored persistently. The fix adds KFD_QUEUE_TYPE_MAX as a structural bound and derives mqd_size from queue_type rather than accepting it as independent input — this corrects a dependency modeling error where mathematically-derived parameters were treated as independent.
Beyond patching, treat this as a signal to audit other checkpoint/restore paths in your kernel for similar implicit-trust gaps. The bounds checks themselves are trivial — the vulnerability exists because the mental model treating checkpoint data as self-authenticating consumed the developer attention that would have caught this. That same cognitive trap likely exists elsewhere in specialized subsystems with narrow user bases and low exploitation probability, where the absence of bug reports creates false confidence.