CVE-2025-68190

What it actually does

Unchecked kcalloc failure for WS buffer in amdgpu_atom_execute_table_locked leaves ectx.ws NULL while ws_size is nonzero, causing NULL pointer dereference in atom_get_src_int when accessing workspace entries.

Why it matters to the business

Systems using AMD GPUs may experience kernel crashes or denial of service when memory allocation fails during atom table execution, with higher urgency on widely deployed Linux kernels containing the affected code.

How an attack unfolds

An attacker triggers amdgpu_atom_execute_table_locked with nonzero WS size while the system is under memory pressure so that kcalloc fails, leaving a NULL workspace pointer that is later dereferenced.

How to fix it

Apply the kernel fix in commit 35f3fb86bb0158a298d6834e7e110dcaf07f490c which adds a check for kcalloc failure and returns -ENOMEM; rebuild and deploy updated kernels on all affected systems.

How to confirm the fix worked

Confirm presence of the allocation-failure check and -ENOMEM return in amdgpu_atom_execute_table_locked; test by forcing memory pressure during atom table execution and verify no NULL dereference occurs.

Typical attack path

1. Trigger execution of an AMD GPU atom table with WS allocation request
2. Induce memory pressure to force kcalloc failure
3. Reach atom_get_src_int which dereferences the unset workspace pointer

How to detect it

Inspect kernel logs and crash dumps for NULL pointer dereference stack traces involving amdgpu_atom_execute_table_locked or atom_get_src_int, especially during periods of high memory usage.

• amdgpu_atom_execute_table_locked
• atom_get_src_int
• NULL pointer dereference.*ws

What your security team should do

• Update all Linux kernels containing the AMDGPU driver to the fixed commit
• Reboot systems after kernel upgrade
• Monitor kernel logs for amdgpu atom-related oops until patches are deployed