CVE-2025-38619 in Linux
요약
\~에 의해 VulDB • 2026. 05. 15.
Based on the kernel panic log provided, here is a detailed analysis of the crash, its root cause, and potential solutions.
### **1. Summary of the Crash** * **Type:** Kernel Panic (`Oops - BUG: Fatal exception in interrupt`). * **Trigger:** A `BUG()` check failed inside the kernel's list manipulation code. * **Context:** The crash occurred in an **interrupt context** (specifically, a DMA completion tasklet). * **Subsystem:** **TI CSI2RX** (Texas Instruments Camera Serial Interface 2 Receiver driver) and its DMA engine interaction.
---
### **2. Key Call Trace Analysis**
```text [ 37.991281] __list_del_entry_valid_or_report+0xdc/0x114 (P)
[ 37.996959] ti_csi2rx_dma_callback+0x84/0x1c4
[ 38.001419] udma_vchan_complete+0x1e0/0x344
```
#### **Step-by-Step Breakdown:** 1. **`udma_vchan_complete`**: The UDMA (Ultra DMA) engine has finished processing a buffer. It calls the completion callback for the virtual channel. 2. **`ti_csi2rx_dma_callback`**: This is the specific callback registered by the `ti-csi2rx` driver. It is invoked when a DMA transfer completes. 3. **`__list_del_entry_valid_or_report`**: Inside the `ti_csi2rx_dma_callback`, the driver attempts to remove a buffer from a kernel linked list (likely the `active` or `done` queue). The kernel's list debugging code (`CONFIG_DEBUG_LIST`) detected that the list entry being deleted was **corrupted** or **not properly linked**.
#### **The Root Cause:** The crash is **not** a hardware failure but a **software bug** in the `ti-csi2rx` driver. Specifically: * The driver is trying to delete a `vb2_buffer` (or similar structure) from a list. * The list pointer (`prev` or `next`) of that entry is invalid (e.g., points to itself, is NULL, or points to garbage). * This usually happens due to: * **Double-free:** The buffer was already removed from the list elsewhere. * **Use-after-free:** The buffer structure was freed, but the driver still holds a reference to it. * **Race Condition:** Concurrent access to the list without proper locking. * **Memory Corruption:** The buffer structure was overwritten by a DMA error or driver bug.
---
### **3. Common Causes in TI CSI2RX Driver**
This specific crash pattern (`__list_del_entry_valid_or_report` in `ti_csi2rx_dma_callback`) is a known issue in older versions of the TI CSI2RX driver. Common triggers include:
1. **Buffer Queue Management Bug:** * The driver may be adding a buffer to the `done` list twice. * Or, it may be removing a buffer from the `active` list that was never added (e.g., due to a stream-on/stream-off race).
2. **DMA Error Handling:** * If a DMA transfer fails, the driver might not correctly clean up the buffer list, leading to stale pointers.
3. **Kernel Version Mismatch:** * This bug has been fixed in newer mainline Linux kernels. If you are using an older kernel (e.g., 5.10, 5.15, or 6.1) or a vendor-specific kernel (e.g., TI's SDK), it may contain this bug.
4. **Hardware/Device Tree Issue:** * Incorrect CSI2RX configuration in the Device Tree (e.g., wrong lane count, clock settings) can cause DMA errors, leading to inconsistent buffer states.
---
### **4. Recommended Solutions**
#### **A. Update the Kernel** * **Check your kernel version:** Run `uname -r`. * **If using an older kernel:** Upgrade to a newer mainline kernel (6.6+ is recommended for TI SoCs like AM62x, AM64x, J721E, etc.). The bug has been fixed in recent commits. * Look for commits related to `ti-csi2rx` and `list_del` fixes.
#### **B. Apply Patches (If you cannot upgrade)** If you are stuck on an older kernel, search for patches in the Linux kernel mailing list (LKML) or TI's SDK release notes
If you want to get best quality of vulnerability data, you may have to visit VulDB.