CVE-2026-98179 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix rmmio iounmap skipped on device removal
amdgpu_pci_remove() calls drm_dev_unplug() before fini_sw(), so drm_dev_enter() is already false there and the iounmap() guarded by it is skipped. This .remove path runs on both hot-unplug and plain rmmod, so the register BAR ioremap mapping leaks one instance per unload.
Unmap rmmio unconditionally (guard only on non-NULL) and drop the now unused idx.
(cherry picked from commit dd6f86a97260e5207d3329ad03aa89fdad61b1e6)
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The Linux kernel driver for AMD graphics processing units, specifically the amdgpu subsystem, contained a resource management flaw within its device removal logic. This vulnerability manifests as a memory leak involving hardware register mappings, which occurs during both hot-unplug events and standard module unloading operations. The root cause lies in the incorrect sequencing of cleanup functions within the pci_remove callback handler. Specifically, the function amdgpu_pci_remove invokes drm_dev_unplug prior to calling fini_sw. This ordering results in a state where the device is considered unplugged before the software-specific finalization routine executes. Consequently, subsequent calls to iounmap for the register memory-mapped input/output (rmmio) region are bypassed because they are guarded by a check on drm_dev_enter, which returns false when the device is already marked as unplugged.
From a technical perspective, this defect represents an improper resource deallocation pattern that leads to kernel space memory leaks. Each time the driver module is unloaded or the hardware device is removed from the system bus without proper unmap operations, one instance of the ioreap mapping remains allocated in the kernel address space. Over repeated cycles of loading and unloading the driver, these leaked mappings accumulate, potentially consuming significant amounts of non-swappable memory reserved for direct hardware access. This type of error falls under CWE-401, which describes a missing release of memory after effective usage, or more specifically CWE-772 regarding Missing Release of Resource after Effective Lifetime. The failure to properly unmap the BAR (Base Address Register) regions means that the kernel retains references to physical hardware addresses even though the driver has detached from the device, violating standard resource lifecycle management principles in operating system kernels.
The operational impact of this vulnerability is primarily related to long-term system stability and resource exhaustion rather than immediate security exploitation or privilege escalation. While a simple memory leak might seem benign, persistent leaks in kernel space can lead to increased pressure on the buddy allocator for high-order pages, potentially causing allocation failures under heavy load conditions. In extreme cases where the driver is frequently cycled due to testing scripts or automated management tools, this could contribute to system instability or out-of-memory scenarios affecting other critical subsystems that rely on contiguous memory allocations. Although there are no direct indications of remote code execution or local privilege escalation vectors associated with this specific flaw, it degrades the reliability and robustness of the graphics stack over extended uptime periods involving driver reloads.
To mitigate this issue, the fix involves modifying the amdgpu_pci_remove function to unmap the rmmio region unconditionally, provided that the pointer is not null. This change ensures that the hardware register mappings are released regardless of whether drm_dev_enter returns true or false, effectively decoupling the resource cleanup from the device state flag used for other synchronization purposes. By dropping the unused index variable and enforcing a direct iounmap call during removal, the driver adheres to proper resource management practices where every allocation has a corresponding deallocation path that is always executed upon detachment. This correction aligns with best practices outlined in industry standards for kernel development, emphasizing deterministic cleanup routines that do not depend on transient state flags which may be altered by preceding function calls. System administrators and developers should ensure they are running patched versions of the Linux kernel to prevent these cumulative memory leaks from impacting system performance over time.