CVE-2026-98784 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/gfx6: fix firmware leak on teardown
The firmware requested in gfx_v6_0_init_microcode() is not released when the GFX block is torn down, leaking the firmware resources.
Add gfx_v6_0_free_microcode() and call it from gfx_v6_0_sw_fini() to release the PFP, ME, CE and RLC firmware.
(cherry picked from commit 386e81346f95ab0be5a82c5535de932e7a456924)
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel driver for AMD Graphics Processing Units, specifically within the GFX v6 architecture, contained a resource management flaw that resulted in memory leaks during device teardown. This vulnerability stems from an asymmetry in the lifecycle management of firmware blobs loaded by the graphics subsystem. When the gfx_v6_0_init_microcode function is invoked to initialize the hardware block, it requests and loads several distinct microcode images required for operation, including those for the PFP (Predicate Fetch Processor), ME (Micro Engine), CE (Compute Engine), and RLC (Run List Controller). These firmware segments are allocated in kernel memory space to facilitate direct communication between the driver and the GPU hardware. However, upon the termination of this graphics block or during device removal procedures, the corresponding cleanup routine was missing. Consequently, while the resources were successfully acquired at initialization time, they were never released when the GFX block was torn down, leading to a persistent leak of kernel memory pages that are not reclaimed until system reboot.
From a technical perspective, this issue is classified as an improper resource release or memory leak within the device driver layer. The absence of a dedicated free function means that every time the graphics subsystem is initialized and subsequently destroyed, such as during module reloading, hot-plug events involving AMD GPUs, or suspend-resume cycles where hardware state might be reset, small amounts of kernel memory are permanently lost. Over extended periods of operation with frequent initialization-destruction cycles, this can contribute to gradual degradation in system performance due to increased pressure on the kernel's page allocator and reduced available contiguous memory for other critical operations. While individual leaks may appear negligible, they represent a failure in adhering to strict resource management protocols expected in low-level driver development, where every allocation must have a corresponding deallocation path under all execution branches.
The operational impact of this vulnerability is primarily related to system stability and long-term reliability rather than immediate security exploitation for privilege escalation or remote code execution. However, sustained memory leaks can eventually lead to out-of-memory conditions within the kernel space, potentially causing driver crashes, GPU hangs, or broader system instability if sufficient memory pressure accumulates. In environments where AMD GPUs are subjected to frequent state changes or dynamic reconfiguration, such as in virtualized cloud instances or high-throughput computing clusters, these leaks could exacerbate resource exhaustion issues. The vulnerability does not expose sensitive data directly but undermines the integrity of the kernel's memory management subsystem by allowing allocations to escape garbage collection mechanisms inherent to normal process termination since this occurs at a lower driver level that persists across user-space application boundaries.
Mitigation for this issue involves applying the upstream Linux kernel patch that introduces the gfx_v6_0_free_microcode function and ensures it is correctly invoked from the gfx_v6_0_sw_fini routine during teardown sequences. This fix explicitly releases the PFP, ME, CE, and RLC firmware blobs allocated earlier in the initialization phase, restoring symmetry to the resource lifecycle. System administrators should ensure that their Linux distributions are updated with kernel versions containing this commit or its equivalent backport for AMD GPU drivers. For organizations running custom kernels, integrating this specific change into the driver source code is necessary to prevent further accumulation of leaked memory resources. Regular monitoring of kernel memory usage and dmesg logs can help identify if similar resource leaks persist in other parts of the graphics stack after applying updates.
In terms of industry standards, this vulnerability aligns with CWE-401, which describes a missing release of memory after effective lifetime, indicating a failure to properly clean up allocated resources. It also relates to CWE-772, regarding Missing Release of Resource after Effective Lifetime, specifically within the context of device drivers and kernel modules where resource leaks can have more severe systemic consequences than in user-space applications. From an ATT&CK perspective, while this is not directly exploitable for initial access or persistence by external attackers, it falls under techniques related to Defense Evasion through resource exhaustion if leveraged in a denial-of-service context against the host system's stability. The fix ensures compliance with robust software engineering practices that mandate balanced allocation and deallocation operations throughout all code paths of critical infrastructure components like GPU drivers.