CVE-2024-49913

What it actually does

Null pointer dereference in commit_planes_for_stream when top_pipe_to_program is null before accessing stream_res, allowing kernel crash via unvalidated pointer in AMD display pipeline.

Why it matters to the business

Linux systems with AMD GPUs may experience kernel panics or instability during graphics operations, leading to downtime, data loss risk, and operational disruption; high ecosystem prevalence in server and desktop distributions increases exposure.

How an attack unfolds

An attacker triggers graphics plane commit operations on streams under conditions where top_pipe_to_program is null, dereferencing the pointer and crashing the kernel; similar Linux kernel memory issues have been targeted by espionage and financially motivated actors in 2024 campaigns.

How to fix it

Upgrade to fixed kernel commit 1ebfa6663807c144be8c8b6727375012409d2356 or equivalent stable patches that insert the null check for top_pipe_to_program before stream_res access; apply vendor kernel updates promptly given publication date and ongoing kernel exposure.

How to confirm the fix worked

Inspect dc.c around line 4140 in commit_planes_for_stream for the added null guard on top_pipe_to_program; confirm patch application via kernel version or source diff and test graphics workloads post-update.

Typical attack path

1. Gain local or remote access to trigger graphics workloads on vulnerable AMD hardware
2. Manipulate display or plane commit sequences to reach commit_planes_for_stream with null top_pipe_to_program
3. Trigger null dereference to induce kernel panic or denial of service

How to detect it

Scan kernel logs and dmesg for null pointer dereference oops referencing commit_planes_for_stream, dc.c:4140, or top_pipe_to_program; correlate with AMD display driver activity and prior uninitialized resource or out-of-bounds kernel events.

• commit_planes_for_stream
• top_pipe_to_program
• dc.c:4140
• we previously assumed 'top_pipe_to_program' could be null

What your security team should do

• Prioritize kernel updates on all AMD Linux systems within remediation windows
• Enable kernel panic logging and monitoring for display-related oops
• Restrict untrusted graphics or display workloads until patched
• Review downstream dependents and rebuild custom kernels with the fix