CVE-2024-26833

What it actually does

Memory leak in dm_sw_fini() where dmub_srv is destroyed but associated memory is not freed after kmalloc_trace allocation in dm_dmub_sw_init.

Why it matters to the business

Gradual kernel memory exhaustion on AMD GPU systems can cause performance degradation, instability, or eventual denial of service after prolonged driver initialization cycles.

How an attack unfolds

An attacker triggers repeated amdgpu driver load/unload or probe sequences to allocate dmub_srv objects that are never freed, slowly consuming kernel memory until exhaustion.

How to fix it

Apply the upstream kernel fix that frees dmub_srv after destruction in dm_sw_fini(). For affected Solana rbpf packages update to commit 5afcc2f570fc7d00b5ed2176239087594d26d3b4.

How to confirm the fix worked

Confirm the fix is present by inspecting the dm_sw_fini function for the free call after dmub_srv destroy; monitor for absence of the kmalloc_trace backtrace in kmemleak reports.

Typical attack path

1. Load or probe amdgpu PCI device to invoke amdgpu_pci_probe
2. Call amdgpu_device_init which reaches dm_sw_init and dm_dmub_sw_init
3. Trigger dm_sw_fini to destroy dmub_srv without freeing the allocation
4. Repeat the cycle to accumulate unreferenced 1024-byte objects

How to detect it

Inspect kernel logs and kmemleak reports for unreferenced objects allocated from dm_dmub_sw_init with backtrace containing amdgpu_device_init and dm_sw_init; watch for repeated udev-worker processes triggering PCI probe.

• unreferenced object 0xffff896302b45800 (size 1024)
• dm_dmub_sw_init+0xb4/0x450 [amdgpu]
• dm_sw_init+0x15/0x2b0 [amdgpu]
• amdgpu_device_init+0x1417/0x24e0 [amdgpu]

What your security team should do

• Prioritize kernel updates on all AMD GPU hosts within the next maintenance window
• Enable kmemleak or similar kernel memory debugging in test environments to validate the leak is resolved
• Monitor EPSS and KEV status for any change indicating increased exploit activity