CVE-2023-52691

What it actually does

Double-free in AMD GPU power management initialization (si_dpm_init) when vddc_dependency_on_dispclk allocation fails, causing amdgpu_free_extended_power_table to be invoked twice via error paths in si_dpm_sw_init and si_dpm_fini.

Why it matters to the business

Risk of kernel memory corruption leading to crashes or potential local code execution on AMD-based Linux systems; low EPSS and no KEV listing indicate limited real-world exploitation but the 882-day-old issue still requires patching to maintain system stability across deployments.

How an attack unfolds

An attacker with local access triggers the allocation failure condition during si_dpm_sw_init on AMD hardware; the error path calls the free function, then the dpm_failed label invokes si_dpm_fini which frees the same structures again, resulting in heap corruption that may be leveraged for further attacks. No known threat actors have exploited this based on available data.

How to fix it

Apply the upstream Linux kernel fix corresponding to commit d0aeeaf5979fbdbf80dc3a3227d6c58442ab7487 or later equivalent patches that prevent the duplicate call to amdgpu_free_extended_power_table; update affected packages to versions containing this resolution.

How to confirm the fix worked

Verify kernel source or binary no longer contains the double invocation of amdgpu_free_extended_power_table in si_dpm_sw_init error paths; test initialization under simulated allocation failure conditions on AMD hardware.

Typical attack path

1. Obtain local access on target Linux system with AMD GPU
2. Force allocation failure for dyn_state.vddc_dependency_on_dispclk.entries during si_dpm_init
3. Allow control flow to reach dpm_failed label triggering second free
4. Exploit resulting double-free for memory corruption or denial of service

How to detect it

Review kernel logs for oops/panic messages involving si_dpm_fini or amdgpu_free_extended_power_table during boot or driver init; correlate with AMD GPU hardware presence and power management initialization failures.

What your security team should do

• Prioritize patching Linux kernels on AMD GPU systems within standard maintenance windows given stable low EPSS
• Audit custom or downstream kernels for the si_dpm_init double-free pattern
• Monitor vendor advisories for backported fixes in distribution kernels