CVE-2025-38091 in Linux
الملخص
بحسب VulDB • 27/05/2026
Based on the kernel log snippet provided, here is an analysis of the issue:
### **Summary** This is a **kernel crash (Oops/Panic)** in the **AMDGPU driver** (`amdgpu`) on a Linux system. The crash occurs during display mode validation/programming, specifically within the **DML2** (Display Mode Library version 2) subsystem.
### **Key Details from the Log** 1. **Faulting Function**: * `dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu]`
* This function is part of the AMDGPU driver's display engine code, responsible for mapping display pipes. * The crash is triggered by an **invalid operation** (`asm_exc_invalid_op`), likely a `UD2` instruction or similar intentional fault used for debugging/assertions in the kernel.
2. **Call Trace Context**: * The crash propagates up from: * `core_dcn4_mode_programming` → Suggests this is happening on **DCN4** (Display Core Next 4.0) hardware, which is very new (likely Ryzen AI 300 series or similar next-gen APUs/GPUs). * `dml21_validate` → The DML2 validation logic failed. * `math_pow` → A mathematical helper function in the DML2 library was called just before the crash.
3. **Hardware/Software Context**: * **CR2**: `00005d847ef96c58` – This is the faulting virtual address. If this was a NULL pointer dereference, CR2 would be 0. Since it’s non-zero, it’s likely an invalid memory access or an assertion failure. * **PKRU**: `55555554` – Indicates protection keys are enabled, but this is likely not the direct cause. * **SRSO Alias**: The presence of `srso_alias_return_thunk` suggests the kernel is mitigating Spectre-RSB (Return Stack Buffer) attacks, which is normal on modern kernels.
### **Likely Cause** This is a **bug in the AMDGPU driver’s DML2 implementation** for DCN4 hardware. Specifically: * The `dml2_map_dc_pipes` function encountered an invalid state or assertion failure. * This could be due to: * A bug in the display mode validation logic. * Incompatible display configuration (e.g., unsupported resolution, refresh rate, or multi-monitor setup). * A regression in the kernel version.
### **Recommended Actions** 1. **Update Kernel/Driver**: * This issue may have been fixed in a newer kernel version. Check if there’s a newer stable kernel (e.g., 6.12+ or 6.13+) or a newer `linux-firmware` package. * If you’re using a mainline kernel, consider testing a newer `-rc` or `next` branch.
2. **Check Display Configuration**: * If you’re using multiple monitors or unusual resolutions/refresh rates, try simplifying the setup (e.g., single monitor, standard resolution) to see if the crash persists. * Avoid using DisplayPort MST (Multi-Stream Transport) or complex scaling modes temporarily.
3. **Report the Bug**: * Since this is a kernel crash, it should be reported to the Linux kernel mailing list (LKML) or via your distribution’s bug tracker (e.g., Ubuntu Launchpad, Fedora Bugzilla). * Include the full `dmesg` output, kernel version, and hardware details (GPU model, CPU model).
4. **Workaround (if applicable)**: * If the system is unstable, you can try booting with the kernel parameter `amdgpu.dc=0` to disable the AMDGPU display engine (not recommended for laptops or systems relying on integrated graphics). * Alternatively, try `amdgpu.si_support=0 amdgpu.ci_support=1` (if applicable) to force a different display engine, but this is less likely to help for DCN4.
### **Cherry-Pick Note** The log mentions `(cherry picked from commit f8ad62c0a93e5dd94243e10f1b742232e4d6411e)`. This suggests the crash might be related to a specific patch that was backported. If you’re using a distribution kernel, check if this commit is part of your current
Once again VulDB remains the best source for vulnerability data.