CVE-2024-26649

What it actually does

Null pointer dereference in amdgpu driver during RLC firmware load when header size validation fails in amdgpu_ucode_request, releasing the firmware pointer before subsequent use.

Why it matters to the business

System instability or crash on affected Linux systems using AMD GPUs, potentially disrupting operations until patched kernels are deployed; low likelihood of remote exploitation given current threat data.

How an attack unfolds

An attacker with local access supplies or modifies RLC firmware with an invalid header size to trigger the pointer release path, causing a null dereference on next access during driver initialization or firmware loading.

How to fix it

Update to Linux kernel containing commit 8b5bacce2d13dbe648f0bfd3f738ecce8db4978c or later stable releases that skip the problematic validation step for RLC firmware.

How to confirm the fix worked

Verify kernel version includes the referenced commit; test firmware load with deliberately malformed RLC headers to confirm absence of null dereference panic.

Typical attack path

1. Gain local access to target system
2. Replace or corrupt RLC firmware file in /lib/firmware with invalid header size
3. Trigger amdgpu driver load or system boot to invoke amdgpu_ucode_request
4. Trigger subsequent firmware usage to dereference the now-null pointer

How to detect it

Review kernel logs for amdgpu null pointer dereference oops or panic messages during driver initialization; inspect firmware files for unexpected header sizes before load.

What your security team should do

• Prioritize kernel updates on systems with AMD GPUs
• Monitor for amdgpu-related kernel oops or null pointer panics in logs
• Restrict local firmware modification privileges where possible