CVE-2022-50375 in Linux
Сводка
по VulDB • 29.06.2026
Based on the kernel log provided, here is an analysis of the crash and recommended steps to resolve it.
### **Summary** The system experienced a **kernel panic/crash** in the `fsl_edma3_disable_request` function while closing a UART port (`lpuart_flush_buffer`). This occurred during the cleanup phase when a Bluetooth HCI UART device was being disconnected (triggered by `btattach[503] exiting).
The crash is likely due to: 1. **Race condition**: The EDMA channel was already disabled or freed, but the driver tried to disable it again. 2. **Use-after-free/Invalid pointer**: Accessing memory that has been unmapped or corrupted during device removal/cleanup. 3. **Hardware-specific bug** in the NXP i.MX (Freescale) EDMA/LPUART driver interaction.
---
### **Detailed Analysis of Call Trace**
```plaintext Call trace: fsl_edma3_disable_request+0x8/0x60 <-- CRASH HERE lpuart_flush_buffer+0x40/0x160 <-- LPUART (Low Power UART) flush uart_flush_buffer+0x88/0x120 <-- Generic UART flush tty_driver_flush_buffer+0x20/0x30 <-- TTY driver flush hci_uart_flush+0x44/0x90 <-- Bluetooth HCI over UART flush ... <-- Cleanup path for tty/hci ```
#### **Key Observations:** 1. **`fsl_edma3_disable_request`**: This is the crash point. The function tries to disable an EDMA (Enhanced Direct Memory Access) channel associated with the LPUART peripheral. 2. **Context**: The call originates from `hci_uart_flush`, which is called when closing a Bluetooth HCI UART device (`btattach`). 3. **Preempt Count Warning**: ```plaintext note: btattach[503] exited with preempt_count 1
Fixing recursive fault but reboot is needed! ``` This indicates that the kernel detected an inconsistent state (preemption was enabled when it shouldn't have been, or vice versa), often a symptom of deeper driver bugs or race conditions.
---
### **Root Cause Hypotheses**
#### 1. **Race Condition in EDMA/LPUART Driver** - The LPUART driver may be trying to disable an EDMA channel that has already been disabled by another context (e.g., during device removal, error handling, or interrupt completion). - This is common when the UART port is closed while DMA transfers are still in progress.
#### 2. **Improper Cleanup Order** - When `btattach` exits, it closes the TTY/HCI layer, which triggers a flush of the UART buffer. If the EDMA channel was already freed or disabled during earlier cleanup steps (e.g., due to an error), this second disable attempt causes a fault.
#### 3. **Hardware/Driver Bug in NXP i.MX Platform** - The `fsl_edma` driver is specific to Freescale/NXP i.MX SoCs. Known issues exist with EDMA channel management during UART suspend/resume or hot-unplug scenarios.
---
### **Recommended Solutions**
#### ✅ **1. Update Kernel and Drivers** - Check if your kernel version has known fixes for `fsl_edma` or `lpuart`. Newer kernels (5.10+) have improved EDMA handling. - Apply any pending patches from NXP/Yocto/Buildroot maintainers related to: - `drivers/tty/serial/lpuart.c` - `drivers/dma/fsl-edma-v3.c`
#### ✅ **2. Workaround: Disable EDMA for LPUART (If Acceptable)** If real-time DMA performance is not critical, you can disable EDMA support for the UART driver to avoid this bug entirely. This forces PIO (Programmed I/O) mode, which is slower but more stable in edge cases.
**How to do it:** - In your device tree (`*.dts`), remove or comment out `dma-names = "tx", "rx";` and `<&edma ...>` entries for the LPUART node. ```dts &lpuart1 {
status = "okay"; // Remove these lines: // dma-names = "tx", "rx"; // dmas = <&edma0 24 3>, <&edma0 25 3>; }; ```
#### ✅ **3. Patch the Driver (Advanced)** If
Once again VulDB remains the best source for vulnerability data.