CVE-2024-36022 in Linux
Summary
by MITRE • 05/30/2024
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Init zone device and drm client after mode-1 reset on reload
In passthrough environment, when amdgpu is reloaded after unload, mode-1 is triggered after initializing the necessary IPs, That init does not include KFD, and KFD init waits until the reset is completed. KFD init is called in the reset handler, but in this case, the zone device and drm client is not initialized, causing app to create kernel panic.
v2: Removing the init KFD condition from amdgpu_amdkfd_drm_client_create. As the previous version has the potential of creating DRM client twice.
v3: v2 patch results in SDMA engine hung as DRM open causes VM clear to SDMA before SDMA init. Adding the condition to in drm client creation, on top of v1, to guard against drm client creation call multiple times.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 05/07/2026
The vulnerability in question affects the amdgpu driver within the Linux kernel, specifically addressing issues that arise during device reinitialization in passthrough environments. This flaw manifests when the amdgpu module is unloaded and subsequently reloaded, triggering a mode-1 reset sequence that initializes necessary IP blocks but omits the KFD (Kernel Fire and Forget) initialization process. The fundamental issue stems from the asynchronous nature of component initialization where the KFD subsystem depends on completion of the reset operation before it can properly initialize its zone device and drm client components. This dependency chain creates a race condition that can lead to kernel panics when applications attempt to interact with the graphics subsystem during this transitional state.
The technical implementation flaw occurs in the driver's reset handling mechanism where the KFD initialization process is scheduled to occur within the reset handler context, but this handler executes before the zone device and drm client components have been properly established. This creates a scenario where application code attempts to create kernel-level resources that do not yet exist or are in an inconsistent state, directly violating the principle of proper resource initialization order as defined by CWE-691. The vulnerability specifically impacts systems using AMD graphics hardware in virtualized environments where device passthrough is employed, making it particularly relevant to cloud computing and containerization scenarios.
The operational impact of this vulnerability extends beyond simple system instability to potential data loss and service disruption in production environments. When applications attempt to establish graphics contexts or perform GPU operations during the reload sequence, the kernel panic resulting from the uninitialized components can cause complete system crashes. This affects not only individual user sessions but can also compromise entire virtual machine instances or containerized applications that depend on GPU acceleration. The vulnerability aligns with ATT&CK technique T1490 which describes 'Inhibit System Recovery" through kernel-level disruptions, potentially allowing attackers to exploit this instability for denial of service attacks.
Multiple patches were developed to address this issue, each building upon previous attempts to resolve the initialization order problem. Version two of the patch attempted to remove the KFD initialization condition from the drm client creation function but introduced a new vulnerability where the SDMA engine would hang due to premature VM clearing operations before SDMA initialization was complete. This demonstrates a classic case of introducing one security flaw while attempting to fix another, highlighting the complexity of kernel-level resource management. Version three addressed this by adding proper conditional guards to the drm client creation process, preventing multiple calls that could cause SDMA engine hangs while maintaining the necessary initialization sequence. The resolution ultimately requires careful orchestration of component initialization order, ensuring that all prerequisite subsystems are properly established before dependent components attempt to access them.
The vulnerability represents a significant concern for enterprise environments using AMD GPU hardware in virtualized or containerized deployments where device reload operations might occur during normal system maintenance or application deployment cycles. Organizations should prioritize applying the patched kernel versions as this issue can lead to unauthorized service disruption and potential data integrity concerns when systems crash due to kernel panics. The fix demonstrates the critical importance of proper initialization sequencing in kernel drivers, particularly for graphics subsystems where multiple complex components must coordinate their startup procedures. This vulnerability underscores the need for comprehensive testing of device reset and reload scenarios in production environments and highlights the risks associated with insufficient validation of component dependencies in kernel-space code.