Linux Kernel CVE-2026-97429

Requires local access to the AMD KFD compute interface (the /dev/kfd render/device node) on a system running an AMD GPU with the amdkfd driver and ROCm/compute workloads active. Exploitation depends on winning a race: the attacker must trigger a queue destroy concurrently with a queue resume so that destroy_queue_cpsch() frees the queue during the lock-drop window in wait_on_destroy_queue(). Limiting factors: no remote reach (AV:L), local low-privilege GPU-device access is needed (PR:L), the race window is narrow and timing-dependent (raising practical attack complexity), and systems without AMD GPUs or without the KFD compute path enabled are not affected.

This is a CWE-416 use-after-free race in the Linux amdkfd (AMD Kernel Fusion Driver / ROCm compute) queue-destruction path: wait_on_destroy_queue() drops locks while waiting for queue resume, letting a concurrent destroy_queue_cpsch() free the queue that is then dereferenced. The NVD/Linux CVSS of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) overstates real-world risk for two reasons. First, AC:L is optimistic - the flaw is a lock-drop race window that requires two threads concurrently destroying/resuming the same KFD queue with precise timing, which in practice is AC:H and not reliably repeatable. Second, C:H/I:H/A:H treats a UAF as full disclosure+integrity+availability; realistically this is a crash-dominant memory-corruption bug whose most likely outcome is a kernel oops/DoS, with information disclosure only theoretical. There is no EPSS score, no CISA KEV listing, and no public POC, so this is no public exploit identified at time of analysis. My assessed severity is ~5.x. Note the CVSS attack vector (AV:L, local) is consistent with the description - local GPU-device access is genuinely required - so there is no network/local conflict here. Overall: a legitimate local memory-safety fix worth patching on AMD-GPU compute hosts, but not an urgent, widely-exploitable priority.

A local user with access to the AMD KFD device (render node) issues concurrent queue-destroy and queue-resume operations to hit the narrow lock-drop window in wait_on_destroy_queue(), causing one thread to free the queue while another still references it. Winning the race triggers a use-after-free that most likely crashes the kernel (DoS); reliable code execution or data leakage would require additional heap-grooming primitives. No public exploit code exists.