CVE-2023-52782 in Linux
Zusammenfassung
von VulDB • 12.06.2026
Based on the stack trace provided, here is an analysis of the kernel crash (Oops/Panic).
### **Summary** The system crashed in the **`mlx5_core`** driver (Mellanox/NVIDIA ConnectX NICs) while trying to allocate memory (`kmalloc`) during a **Receive Dimensioning (DIM)** work item. The crash occurred in `__kmem_cache_alloc_node`, likely due to a **memory corruption**, **invalid pointer**, or **slab allocator inconsistency**.
---
### **Detailed Stack Trace Analysis**
#### **1. The Crash Point** ``` RIP: 0010:__kmem_cache_alloc_node+0xb/0x330 ``` - The CPU was executing `__kmem_cache_alloc_node`, which is part of the kernel's slab allocator (`kmalloc`). - This function is called to allocate memory from a cache. - The crash suggests that the allocator encountered an invalid state, such as: - A corrupted slab cache. - An invalid pointer passed to the allocator. - A use-after-free or double-free scenario that corrupted internal slab structures.
#### **2. The Caller Chain** ``` cmd_exec+0x796/0x2200 [mlx5_core]
kmalloc_trace+0x26/0xc0 cmd_exec+0x796/0x2200 [mlx5_core]
mlx5_cmd_do+0x22/0xc0 [mlx5_core]
mlx5_cmd_exec+0x17/0x30 [mlx5_core]
mlx5_core_modify_cq_moderation+0x139/0x1b0 [mlx5_core]
mlx5e_rx_dim_work+0x9d/0x100 [mlx5_core]
process_one_work+0x730/0x1220 ``` - **`mlx5e_rx_dim_work`**: This is the **Receive Dimensioning** work function. DIM is a feature in Mellanox drivers that dynamically adjusts the interrupt moderation (CQ moderation) based on traffic load to optimize latency vs. CPU usage. - **`mlx5_core_modify_cq_moderation`**: The DIM work item is trying to modify the Completion Queue (CQ) moderation settings. - **`mlx5_cmd_exec` / `cmd_exec`**: To change CQ moderation, the driver must send a command to the NIC firmware via the **Command Interface (CI)**. This involves allocating a command buffer (`cmd_exec` calls `kmalloc`). - **`process_one_work`**: The work was scheduled on a kernel worker thread.
#### **3. Interrupt Context** ``` __do_softirq+0x26c/0x827 irq_exit_rcu+0xc2/0x100 common_interrupt+0x7f/0xa0 asm_common_interrupt+0x22/0x40 ``` - The crash happened in **softirq context** (interrupt bottom half), not in process context. This is consistent with `mlx5e_rx_dim_work` being scheduled from a softirq (likely the NAPI poll or interrupt handler).
---
### **Root Cause Hypotheses**
#### **1. Memory Corruption (Most Likely)** - The slab allocator (`__kmem_cache_alloc_node`) crashed because its internal data structures were corrupted. - This corruption could have been caused by: - A **use-after-free** in the `mlx5_core` driver or another driver. - A **buffer overflow** in a previous `mlx5` command execution. - A bug in the kernel's memory management subsystem.
#### **2. Invalid Pointer in `cmd_exec`** - The `cmd_exec` function might be passing an invalid or corrupted pointer to `kmalloc` or its internal cache. - Check if `cmd_exec` is using stale pointers or if the `mlx5_cmd_info` structure is corrupted.
#### **3. Race Condition in DIM** - The DIM work item (`mlx5e_rx_dim_work`) might be running concurrently with another part of the driver that is freeing or modifying the same resources. - If the CQ or command interface structures are freed while `mlx5e_rx_dim_work` is trying to send a command, it could lead to a crash.
#### **4. Firmware or Hardware Issue** - Less likely, but a firmware bug in the NIC could cause the driver to enter an inconsistent state.
---
### **Recommended Actions**
#### **1. Check for Memory Corruption** - Run **KASAN** (Kernel Address Sanitizer) if available to detect use-after-free or buffer overflows. - Check `d
If you want to get best quality of vulnerability data, you may have to visit VulDB.