CVE-2026-98178 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Skip KFD mapping clear before initialization
amdgpu_amdkfd_clear_kfd_mapping() assumes that a non-NULL kfd_dev has a fully populated node array. This is not true when KFD device initialization fails after probe.
For example, kgd2kfd_device_init() sets num_nodes before checking PCIe atomics support. On Polaris systems without the required atomics, it returns before allocating nodes[0], but the kfd_dev remains attached
to the amdgpu device. A later GPU reset then dereferences nodes[0]->id.
Require the authoritative KFD initialization flag before walking the node array, matching the existing KFD reset and teardown paths.
(cherry picked from commit 4ac1835823c47903fbb278bbf474773c46f59edc)
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified in the Linux kernel's AMD GPU driver, specifically within the amdgpu subsystem and its Kernel Fusion Driver (KFD) interface, represents a critical logic error related to resource initialization and state management. The core issue resides in the function amdgpu_amdkfd_clear_kfd_mapping(), which is responsible for clearing mappings associated with KFD devices during operations such as GPU resets or driver teardowns. This function operates under an incorrect assumption that if a pointer to the kfd_dev structure is non-null, then the internal node array within that structure has been fully populated and initialized. In reality, this assumption fails in specific failure scenarios where device initialization completes partially but does not finish successfully due to hardware capability checks or other early-exit conditions.
The technical flaw manifests when the kernel attempts to initialize a KFD device through kgd2kfd_device_init(). During this process, the system may set internal counters such as num_nodes before verifying critical hardware features like PCIe atomic operations support on specific architectures, notably Polaris systems lacking these atomics. If the required feature is absent, the initialization routine returns an error code to abort further setup without allocating memory for or populating the nodes array elements, specifically nodes[0]. However, despite this early termination of the initialization sequence, the kfd_dev structure remains attached and linked to the amdgpu device context. This creates a state inconsistency where the driver believes it has control over a KFD device that is only partially initialized.
The operational impact of this vulnerability becomes apparent during subsequent GPU reset events or when the system attempts to clean up resources associated with the device. Because the kfd_dev pointer remains valid and non-null, the amdgpu_amdkfd_clear_kfd_mapping() function proceeds to walk the node array expecting it to contain valid pointers. Since nodes[0] was never allocated due to the earlier initialization failure, accessing nodes[0]->id results in a null pointer dereference or an invalid memory access. This typically leads to a kernel panic, causing system instability and requiring a hard reboot of the affected machine. The severity is compounded by the fact that GPU resets can be triggered automatically by hardware errors or manually by userspace tools, making this vulnerability potentially exploitable for denial-of-service attacks through routine device interaction rather than complex exploitation techniques.
From a classification perspective, this flaw aligns with CWE-476, which denotes NULL Pointer Dereference vulnerabilities arising from improper checks of pointer validity before use. It also relates to CWE-823, Use of Out-of-range Pointer Offset, as the code attempts to access an array element that was never allocated due to premature exit during initialization. In terms of the MITRE ATT&CK framework, this vulnerability facilitates Denial of Service (T1499) by allowing a local user or automated system processes to crash the kernel through standard GPU reset operations. The root cause is fundamentally a logic error in state management where the driver fails to track whether KFD initialization was fully successful before permitting cleanup routines that depend on complete data structures.
The resolution implemented requires checking an authoritative KFD initialization flag before attempting to walk or access the node array. This change ensures that amdgpu_amdkfd_clear_kfd_mapping() only proceeds with dereferencing nodes if the device has passed all necessary initialization checks, including PCIe atomic support verification. This approach mirrors existing patterns used in other parts of the driver codebase for KFD reset and teardown paths, thereby enforcing consistency across the subsystem's lifecycle management functions. By validating the complete initialization status prior to accessing internal structures, the patch eliminates the possibility of dereferencing uninitialized or null pointers during error handling sequences.
To mitigate this vulnerability on systems where immediate kernel updates are not feasible, administrators should monitor for GPU reset events and ensure that drivers are updated as soon as patches become available in their distribution repositories. For environments running affected Polaris architecture hardware without PCIe atomic support, special attention should be paid to stability logs indicating sudden system crashes following GPU activity or resets. Long-term mitigation involves ensuring strict adherence to initialization state checks throughout the driver's lifecycle, preventing partial states from persisting into operational phases where they are assumed to be fully formed. This incident highlights the importance of rigorous state validation in kernel drivers, particularly when dealing with hardware-specific feature detection that can cause early exits during complex initialization sequences.