CVE-2026-98179

What it actually does

The vulnerability causes a leak of the register BAR ioremap mapping because drm_dev_unplug() disables drm_dev_enter() before fini_sw() runs in amdgpu_pci_remove(), skipping the guarded iounmap on both hot-unplug and rmmod paths.

Why it matters to the business

Repeated driver unloads or device removals gradually exhaust kernel memory mappings, increasing the risk of resource exhaustion, degraded GPU functionality, or system instability in environments that frequently reload the amdgpu driver.

How an attack unfolds

An attacker with local privileges triggers repeated amdgpu device removal or module unload operations; each cycle skips the iounmap, accumulating leaked mappings until memory pressure or denial of service occurs. No remote or unauthenticated vectors exist and no threat actors are known to exploit it.

How to fix it

Apply the upstream fix that performs unconditional rmmio unmap when the pointer is non-NULL; update to a Linux kernel containing commit dd6f86a97260e5207d3329ad03aa89fdad61b1e6 or later backports. Reboot after installing the updated kernel package.

How to confirm the fix worked

Confirm the presence of the fix by inspecting the amdgpu_pci_remove() path for an unconditional iounmap guarded only by a non-NULL check and verify that the drm_dev_enter() guard and unused idx have been removed; test repeated module load/unload cycles while monitoring ioremap accounting.

Typical attack path

1. Obtain local root or sufficient privileges to unload the amdgpu module or trigger PCI hot-unplug
2. Repeatedly execute rmmod or equivalent removal operations
3. Each removal leaks one rmmio mapping instance
4. Accumulate leaks until kernel memory or mapping resources are exhausted

How to detect it

Examine kernel logs for repeated amdgpu removal events, track ioremap and iounmap call counts around module unload, and monitor for gradual increases in kernel memory mappings without corresponding frees; no public exploit artifacts are known.

What your security team should do

• Prioritize kernel updates on systems using AMD GPUs that experience frequent driver reloads or hot-unplug events
• Monitor kernel memory and ioremap usage statistics after updates to confirm leak resolution
• Restrict unprivileged access to module unloading and PCI device management where feasible