CVE-2024-41060

What it actually does

Use-after-free in drm/radeon where radeon_vm_clear_freed can null bo_va->bo and a subsequent dereference occurs without a NULL check, resulting in invalid kernel memory access.

Why it matters to the business

Linux systems with Radeon graphics hardware face risk of kernel crashes, denial of service, or local privilege escalation; high ecosystem prevalence in servers and workstations increases urgency for patching despite low EPSS.

How an attack unfolds

An attacker triggers Radeon VM operations that invoke radeon_vm_clear_freed to clear bo_va->bo then arranges a code path that dereferences the now-NULL pointer, enabling use-after-free exploitation for memory corruption or code execution; listed threat actors involved in Linux kernel exploitation campaigns could leverage similar patterns.

How to fix it

Update the Linux kernel to include commit e8d3c53c6f1cccea9c03113f06dd39521c228831 or any later stable release containing the null check before dereferencing bo_va->bo.

How to confirm the fix worked

Inspect the drm/radeon source for the added NULL check on bo_va->bo before use, or confirm the running kernel contains commit e8d3c53c6f1cccea9c03113f06dd39521c228831.

Typical attack path

1. Trigger Radeon VM operations that call radeon_vm_clear_freed
2. Clear bo_va->bo without immediate re-assignment
3. Execute code path that dereferences bo_va->bo
4. Exploit resulting use-after-free for kernel memory corruption or privilege escalation

How to detect it

Monitor kernel logs for oops/panics referencing radeon_vm_clear_freed or drm/radeon NULL dereferences; correlate with process activity involving Radeon graphics contexts or VM mappings.

What your security team should do

• Apply the fixed kernel commit or equivalent stable update within 30 days given publication age and listed kernel exploitation campaigns
• Prioritize systems with Radeon hardware in graphics or compute workloads
• Re-test graphics and VM-related workloads after patching to confirm stability