CVE-2023-52470

What it actually does

Unchecked return value from alloc_workqueue in radeon_crtc_init leads to null pointer dereference and kernel crash (DoS).

Why it matters to the business

Linux systems using older Radeon graphics hardware may experience unexpected crashes and downtime; low exploitation likelihood after nearly three years reduces urgency despite wide kernel prevalence.

How an attack unfolds

A local attacker with user privileges loads or initializes the radeon driver under conditions where workqueue allocation fails, dereferencing the null pointer and triggering a kernel panic; no known threat actors have weaponized this path.

How to fix it

Upgrade the Linux kernel to a version containing commit 21b1645660717d6126dd4866c850fcc5c4703a41 or later stable releases that include the null-check for alloc_workqueue in radeon_crtc_init.

How to confirm the fix worked

Verify kernel source contains the added null return check after alloc_workqueue in radeon_crtc_init; confirm no null-deref oops in dmesg when exercising Radeon CRTC paths on patched kernels.

Typical attack path

1. Obtain local user access on affected Linux system
2. Trigger radeon driver initialization or display configuration that calls radeon_crtc_init
3. Force alloc_workqueue to return null (resource exhaustion or race)
4. Kernel dereferences null pointer resulting in oops/panic

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for radeon_crtc_init null pointer dereference oops entries; correlate with process activity loading the radeon module.

• radeon_crtc_init
• alloc_workqueue.*null
• BUG: unable to handle kernel NULL pointer dereference.*radeon

What your security team should do

• Patch affected kernels to the fixed commit as soon as practical for systems using radeon DRM
• Monitor EPSS and KEV status for any future rise in activity
• Restrict local access on legacy Radeon hardware until patched