CVE-2026-98784

What it actually does

Firmware images for PFP, ME, CE and RLC microcode requested during gfx_v6_0_init_microcode are never released when the GFX block is torn down, leaving the firmware references allocated.

Why it matters to the business

On systems using older AMD GPUs, repeated driver load/unload cycles slowly consume kernel memory and firmware tracking resources, eventually causing instability or requiring a reboot.

How an attack unfolds

An attacker with local access repeatedly triggers graphics driver initialization and teardown (for example via module reload or GPU reset paths) to accumulate unreleased firmware objects until the system becomes unusable.

How to fix it

Update the Linux kernel to a version containing commit 386e81346f95ab0be5a82c5535de932e7a456924 or the equivalent backport that adds gfx_v6_0_free_microcode and calls it from gfx_v6_0_sw_fini.

How to confirm the fix worked

Inspect the amdgpu gfx_v6_0.c source for the presence of gfx_v6_0_free_microcode and its call site in gfx_v6_0_sw_fini; confirm the running kernel was built from a tree that includes the fix.

Typical attack path

1. Obtain local access on a system with an affected AMD gfx6 GPU
2. Trigger repeated gfx driver sw_init / sw_fini cycles
3. Accumulate unreleased firmware references until resource exhaustion

How to detect it

Review kernel logs for repeated amdgpu gfx initialization messages without corresponding free operations; track memory usage of firmware objects across driver reload cycles.

What your security team should do

• Prioritize kernel updates on any hosts still running unpatched amdgpu gfx6 code paths
• Monitor systems for increasing firmware-related memory usage after driver reload events
• Limit unprivileged module loading or GPU reset capabilities where possible