CVE-2024-56542 in Linux
Riassunto
di VulDB • 18/06/2026
Based on the kernel crash log and the description provided, here is an analysis of the issue and the recommended fix.
### **Issue Analysis**
1. **Crash Location**: The kernel panic occurs in `drm_mm_takedown` called from `amdgpu_gtt_mgr_fini`. This indicates a use-after-free or invalid memory access during the cleanup/teardown phase of the AMDGPU driver. 2. **Root Cause**: * The driver is being unloaded/reloaded (likely during a warm boot or driver reload). * During the **second** initialization phase, the **VBIOS DMUB (Display Microcontroller Unit Block)** is not active. * This happens because the PSP (Platform Security Processor) policy retains the driver-loaded VBIOS version on subsequent warm boots, preventing the DMUB from being properly re-initialized or communicated with. * The driver attempts to communicate with the inactive DMUB, leading to a failure that corrupts memory management structures (`drm_mm`), causing the crash during `takedown`.
### **Proposed Fix**
The fix should **abort further communication with the VBIOS DMUB** if it is detected as inactive or if the initialization fails due to the PSP policy. This prevents the driver from proceeding with operations that assume DMUB is active, thereby avoiding the memory corruption.
### **Code Patch Suggestion**
You need to modify the AMDGPU driver code, specifically in the DMUB initialization or communication path. Look for functions like `dmub_srv_init` or similar in `drivers/gpu/drm/amd/display/dc/dmub/dmub_srv.c` or related files.
Here is a conceptual patch:
```c // In drivers/gpu/drm/amd/display/dc/dmub/dmub_srv.c (or similar file)
// Add a check before attempting DMUB communication static int dmub_srv_init(struct dmub_srv *srv, struct amdgpu_device *adev) {
int ret;
// ... existing initialization code ...
// Check if DMUB is active/ready if (!dmub_is_active(srv)) {
DRM_INFO("DMUB is not active, skipping DMUB initialization due to PSP policy.\n"); // Set a flag to indicate DMUB is unavailable srv->dmub_active = false; return 0; // Return success to allow driver to continue without DMUB }
// ... rest of the initialization ... }
// In the function that communicates with DMUB (e.g., dmub_srv_cmd_execute) static int dmub_srv_cmd_execute(struct dmub_srv *srv, struct dmub_cmd *cmd) {
// Add guard check if (!srv->dmub_active) {
DRM_DEBUG_DRIVER("DMUB is not active, aborting command.\n"); return -ENODEV; // Or appropriate error code }
// ... existing command execution code ... } ```
### **Steps to Apply the Fix**
1. **Identify the exact file**: Locate the DMUB service initialization code in your kernel source tree (typically under `drivers/gpu/drm/amd/display/`). 2. **Add the check**: Insert a check to verify if the DMUB is active before attempting any communication. If it's not active, skip the initialization or return an error gracefully. 3. **Set a flag**: Ensure a flag (e.g., `dmub_active`) is set to `false` if the DMUB is not available, so subsequent calls can check this flag. 4. **Recompile and test**: Recompile the kernel/module and test the driver reload scenario.
### **Alternative Workaround**
If you cannot modify the kernel source immediately, you can try:
1. **Disable PSP VBIOS retention**: Check if there's a kernel parameter or BIOS setting to disable the PSP policy that retains the VBIOS. For example, adding `amdgpu.psp_load_vbios=0` to the kernel command line might force a fresh VBIOS load. 2. **Cold Boot**: Perform a full cold boot instead of a warm boot to ensure the VBIOS is re-initialized properly.
### **Conclusion**
The crash is caused by the AMDGPU driver attempting to communicate with an inactive DMUB due to PSP policy during warm boots. The fix is to detect this condition and abort further DMUB communication, allowing the driver to continue without DMUB functionality.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.