CVE-2024-41061

What it actually does

Out-of-bounds array access in dml2_calculate_rq_and_dlg_params() when out_lowest_state_idx exceeds 1 while indexing the FCLKChangeSupport array, caused by an assumption that the index would never exceed the array bounds despite identical element values.

Why it matters to the business

Kernel memory corruption in AMD display code paths can lead to system crashes, instability on graphics workloads, or potential local privilege escalation on affected Linux distributions, increasing operational downtime for GPU-dependent systems.

How an attack unfolds

An attacker with local access crafts display configuration parameters that force out_lowest_state_idx > 1 during dml2 processing, triggering the out-of-bounds read/write in the FCLKChangeSupport array to corrupt adjacent kernel memory for denial-of-service or code execution.

How to fix it

Update the Linux kernel to a version containing commit 94166fe12543fbef122ca2d093e794ea41073a85 which enforces use of index 0 for FCLKChangeSupport accesses; rebuild and deploy the fixed kernel across all affected AMD GPU systems.

How to confirm the fix worked

Confirm the running kernel includes commit 94166fe12543fbef122ca2d093e794ea41073a85 via git log or kernel version strings; test display power state transitions and mode setting under varying FCLK conditions to ensure no crashes occur.

Typical attack path

1. Obtain local user access on a Linux system with AMD display hardware
2. Trigger display mode or power state calculations that set out_lowest_state_idx greater than 1
3. Invoke dml2_calculate_rq_and_dlg_params() to perform the out-of-bounds array access
4. Leverage resulting memory corruption for privilege escalation or system crash

How to detect it

Review kernel logs for array out-of-bounds warnings or crashes originating from dml2_calculate_rq_and_dlg_params(); inspect AMD display driver activity during power state changes for anomalous behavior.

What your security team should do

• Prioritize kernel upgrade to the fixed commit on all AMD GPU hosts within the next patch cycle
• Monitor for kernel oops or display-related panics in system logs as indicators of potential trigger attempts
• Restrict unprivileged local access on systems until patches are applied where feasible