CVE-2024-49917

What it actually does

Null pointer dereference in dcn30_init_hw when dc->clk_mgr or dc->clk_mgr->funcs is null before function pointer access.

Why it matters to the business

Kernel panic or system instability on affected AMD GPUs during display hardware initialization, potentially disrupting workloads on Linux systems with high ecosystem prevalence.

How an attack unfolds

An attacker with local access or the ability to influence display initialization paths triggers dcn30_init_hw under conditions where clk_mgr remains uninitialized, leading to dereference; listed threat actors in Linux kernel campaigns could chain this with other memory corruption primitives for privilege escalation.

How to fix it

Apply the upstream fix from commit 23cb6139543580dc36743586ca86fbb3f7ab2c9d or update sysstat to 0:11.7.3-5.el8 on Rocky Linux 8; rebuild and deploy kernel images containing the null check for clk_mgr and clk_mgr->funcs.

How to confirm the fix worked

Inspect dcn30_hwseq.c around line 789 for the added null guard; verify fixed commit presence via git log; boot test affected AMD hardware configurations to confirm absence of dereference paths.

Typical attack path

1. Gain local execution or kernel module load capability on target system
2. Trigger AMD display hardware initialization sequence involving dcn30_init_hw
3. Supply or induce null clk_mgr state during initialization
4. Cause null dereference leading to panic or controlled corruption

How to detect it

Review kernel logs and dmesg for oops or panic messages referencing dcn30_init_hw or clk_mgr null dereference; correlate with display driver load events on AMD systems.

• dcn30_init_hw
• clk_mgr
• drivers/gpu/drm/amd/display/dc/hwss/dcn30/dcn30_hwseq.c:789

What your security team should do

• Prioritize kernel updates on systems with AMD display hardware within standard patch cycles
• Monitor for related Linux kernel memory corruption reports from the listed threat actors
• Audit downstream dependents for delayed adoption of the fix