CVE-2024-49989

What it actually does

Double free of link encoder objects occurs during amdgpu module unload when flexible endpoints reuse DIGs from inflexible endpoints, causing the same encoder to be destroyed twice via dcn10_link_encoder_destroy and kfree.

Why it matters to the business

Systems using AMD GPUs may experience kernel crashes or instability when the graphics driver is unloaded, leading to unexpected downtime or reduced availability on affected Linux installations.

How an attack unfolds

An attacker with local access triggers amdgpu module unload (for example via rmmod or driver detachment) on a system with vulnerable AMD display hardware; the incorrect encoder freeing logic then executes a double free, resulting in slab corruption and potential privilege escalation or denial of service.

How to fix it

Update the Linux kernel to a version containing commit 43c296870740a3a264cdca9f18db12e12e9cfbdb or later; ensure the amdgpu driver is rebuilt with the corrected encoder freeing logic for inflexible versus flexible endpoints.

How to confirm the fix worked

Confirm the presence of commit 43c296870740a3a264cdca9f18db12e12e9cfbdb in the running kernel source; attempt module unload on test hardware and verify absence of the double-free call trace involving dcn10_link_encoder_destroy.

Typical attack path

1. Obtain local access to a Linux system with an AMD GPU using the amdgpu driver
2. Trigger conditions that cause the amdgpu module to be unloaded
3. Invoke dc_destruct and link_destroy paths that call dcn10_link_encoder_destroy twice on the same object
4. Trigger __slab_free on an already-freed pointer leading to kernel panic or memory corruption

How to detect it

Search kernel logs and dmesg for the call trace containing dcn10_link_encoder_destroy, __slab_free, and amdgpu_dm_fini during module unload; inspect for repeated kfree operations on the same encoder object.

• dcn10_link_encoder_destroy+0x19/0x30 [amdgpu]
• __slab_free+0x152/0x2f0
• amdgpu_dm_fini+0x16e/0x200 [amdgpu]
• RIP: 0010:__slab_free

What your security team should do

• Prioritize kernel updates on all AMD GPU systems within the next maintenance window
• Monitor for kernel oops or slab corruption logs during driver unload operations
• Restrict unprivileged users from unloading kernel modules until patched