CVE-2024-27040

What it actually does

Null pointer dereference in the AMD display driver (edp_set_replay_allow_active) when the replay pointer is NULL after an initial check, allowing a subsequent unconditional access to replay->funcs->replay_set_power_opt.

Why it matters to the business

Potential kernel crashes or denial of service on Linux systems using affected AMD display hardware, leading to system instability and possible data loss or service disruption until patched.

How an attack unfolds

An attacker with the ability to influence display link settings or replay feature state on affected AMD hardware triggers the vulnerable code path in the display driver, causing the kernel to dereference a null pointer and panic.

How to fix it

Update the Linux kernel to a version containing commit f610c46771ef1047e46d61807aa7c69cd29e63d8 or later; rebuild and deploy the updated kernel image on affected systems.

How to confirm the fix worked

Verify the running kernel source contains the fix commit or check that the NULL check precedes the second conditional in link_edp_panel_control.c; test display power optimization paths on AMD hardware post-upgrade.

Typical attack path

1. Obtain local access or ability to configure display/replay settings on a vulnerable kernel
2. Trigger conditions where replay pointer is NULL while replay_feature_enabled is true
3. Cause execution of the unchecked replay_set_power_opt call
4. Induce kernel panic via null dereference

How to detect it

Review kernel logs for null pointer dereference oops in amdgpu or drm/amd/display paths, particularly around link_edp_panel_control or edp_set_replay_allow_active; correlate with display reconfiguration events.

What your security team should do

• Prioritize kernel upgrades on systems with AMD GPUs using the display driver
• Monitor for kernel oops/panic reports related to amdgpu or drm display code
• Apply the fix commit across all maintained kernel branches used in production