CVE-2025-38091 in Linux
Riassunto
di VulDB • 16/06/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`) occurring during display mode validation/programming. The crash happens in the `dml21_validate` function, which is part of AMD's Display Mode Library (DML) version 2.1, used for calculating display engine resources.
### **Key Details from the Log** 1. **Faulting Function**: * `dml21_validate+0x3d4/0x980 [amdgpu]`
* This function validates display configurations (pipes, clocks, bandwidth, etc.) before applying a new mode.
2. **Call Trace Context**: * The crash propagates up from: * `core_dcn4_mode_programming` → Suggests this is on a **DCN4** (Display Core Next 4.0) architecture, which is very new (likely Ryzen AI 300 series or similar next-gen APUs/GPUs). * `math_pow` → Indicates a floating-point or power calculation was being performed. * `dml2_map_dc_pipes` → Pipe mapping logic.
3. **Exception Type**: * `asm_exc_invalid_op` → **Invalid Opcode Exception**. * This typically means the CPU tried to execute an instruction it doesn't support, or there was a memory corruption leading to an invalid instruction pointer. * Given it's in `math_pow`, it could also be related to **SSE/AVX instruction usage** if the CPU state was corrupted or if there's a bug in how floating-point math is handled in the kernel context (though kernel code usually avoids FP unless explicitly enabled).
4. **Registers**: * `CR2: 00005d847ef96c58` → This is the **faulting linear address** for page faults. However, since the exception is `invalid_op`, CR2 might not be directly relevant (it's more for page faults). The `invalid_op` suggests the instruction pointer (`RIP`) was invalid or the opcode was unrecognized. * `R14: ffffbfa383249658` → Likely points to a stack or data structure.
5. **Architecture**: * `DCN4` → This is a **very new** AMD display architecture. Bugs in early-stage DCN4 drivers are more likely.
### **Likely Causes** 1. **Bug in DCN4 DML2.1 Code**: * The `dml21_validate` function has a bug that causes an invalid instruction execution or memory corruption. * The `math_pow` call might be triggering an unhandled exception (e.g., NaN/Inf handling, or using an instruction not supported by the CPU).
2. **CPU Instruction Set Mismatch**: * If the kernel was compiled with AVX/AVX2/AVX-512 optimizations but is running on a CPU that doesn't support them (unlikely for modern DCN4 systems, but possible in VMs or misconfigured environments).
3. **Memory Corruption**: * A previous bug might have corrupted the stack or a function pointer, leading to the `invalid_op`.
4. **SRSO (Speculative Return Stack Overflow) Mitigation**: * The trace shows `srso_alias_return_thunk` multiple times. This is a Spectre v2 mitigation. While unlikely to be the root cause, it can sometimes interact poorly with certain code patterns.
### **Recommended Actions**
#### **1. Update Kernel and Firmware** * This looks like a bug in a **newer kernel** (likely 6.11+ or 6.12-rc) with DCN4 support. * Check if there is a newer kernel version available. The commit hash `f8ad62c0a93e5dd94243e10f1b742232e4d6411e` suggests this is a **cherry-picked fix** from a mainline or AMD tree. Ensure you are running a kernel that includes this fix or a later one.
#### **2. Disable DCN4 or Use Older Display Engine** * If possible, try booting with `amdgpu.dc=0` (disables AMDGPU display engine) to see if the system stabilizes (though this will break display). * Alternatively, try forcing an older DCN version if supported (e.g., `am
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.