CVE-2024-41008

What it actually does

Use-after-free in amdgpu driver caused by improper lifecycle management of the dynamically allocated vm->task_info object; references could be used after the last put freed the structure.

Why it matters to the business

Systems using AMD GPUs may experience kernel crashes, denial of service, or local privilege escalation; widespread impact on Linux servers, workstations, and embedded devices with AMD graphics.

How an attack unfolds

An attacker triggers AMD GPU virtual memory operations that exercise task_info creation and reference counting paths; by racing or manipulating the new get/put helpers, a reference to already-freed task_info is retained and later dereferenced, leading to kernel memory corruption.

How to fix it

Upgrade the Linux kernel to a commit containing a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6 or later; rebuild and reboot with the patched kernel; apply vendor backports for distribution kernels that include the reference-counted task_info helpers.

How to confirm the fix worked

Confirm presence of amdgpu_vm_get_task_info and amdgpu_vm_put_task_info with proper refcounting and NULL checks in the running kernel source or via /proc/version and kernel build logs; test that vm_init obtains the first reference and vm_fini performs the final put.

Typical attack path

1. Obtain local access on a system with AMD GPU
2. Trigger amdgpu VM initialization and task_info allocation via graphics or compute workloads
3. Exploit reference-counting race or missing NULL check to retain dangling pointer
4. Dereference freed task_info to corrupt kernel memory or control flow
5. Escalate to ring 0 or cause system panic

How to detect it

Inspect kernel logs for amdgpu_vm task_info warnings, NULL dereference oops, or use-after-free reports; correlate with processes that perform heavy AMD GPU memory operations.

What your security team should do

• Prioritize kernel updates containing the referenced commit on all AMD GPU systems
• Enable kernel address space layout randomization and stack canaries
• Monitor for amdgpu-related kernel oops/panics in dmesg and central logging
• Restrict unprivileged access to GPU devices until patches are deployed