CVE-2022-50375 in Linux
要約
〜によって VulDB • 2026年05月09日
Linux kernel panic/crash log analysis.
## Summary The system crashed due to a **recursive fault** in the `fsl_edma3_disable_request` function, triggered during UART/Bluetooth subsystem cleanup when a process (`btattach`) was exiting. The kernel detected a recursive fault and forced a reboot.
## Key Details
### Crash Location - **Function**: `fsl_edma3_disable_request+0x8/0x60` - **Call Trace**: 1. `fsl_edma3_disable_request` – EDMA3 controller disable request 2. `lpuart_flush_buffer` – Flush UART buffer 3. `uart_flush_buffer` → `tty_driver_flush_buffer` 4. `hci_uart_flush` – Bluetooth HCI UART flush 5. `tty_ldisc_close` → `tty_ldisc_release` → `tty_release_struct` → `tty_release` 6. `__fput` → `____fput` → `task_work_run` → `do_exit` → `do_group_exit` → `exit_group` syscall
### Root Cause Analysis 1. **Context**: The crash occurred during process exit (`btattach[503]`), specifically during TTY/UART cleanup for a Bluetooth HCI UART device.
2. **Trigger**: `fsl_edma3_disable_request` was called while handling an EDMA3-related operation, likely during UART buffer flush. 3. **Recursive Fault**: The kernel detected a **recursive page fault** (same fault occurring while handling the first fault), which is a severe error indicating: - A null pointer dereference or invalid memory access in `fsl_edma3_disable_request` - Possible race condition or use-after-free in the EDMA3/UART driver - The `preempt_count 1` note suggests the fault occurred in a context where preemption was disabled, making recovery impossible
### Register State (ARM64) - `x0`–`x2`, `x3`, `x5`–`x8` contain kernel virtual addresses (`ffff...`) - `x4` = 0, `x5` = 0 – likely null pointer or zeroed register - The faulting instruction: `b9400041` (LDR W1, [X0]) – **dereferencing x0**, which is `ffff00000559c800`
### Affected Components - **EDMA3 Driver**: `fsl_edma3` (NXP/Freescale EDMA controller) - **UART Driver**: `lpuart` (Low Power UART) - **Bluetooth HCI**: `hci_uart` - **Process**: `btattach` (Bluetooth UART attachment tool)
## Likely Causes 1. **Use-after-free**: The EDMA3 channel or UART structure was freed while still being accessed during cleanup. 2. **Race Condition**: Concurrent access to EDMA3/UART resources during process exit. 3. **Driver Bug**: Missing null pointer check or improper state management in `fsl_edma3_disable_request`. 4. **Hardware/Interrupt Issue**: EDMA3 interrupt or DMA completion handler corrupted state.
## Recommendations
### Immediate Actions 1. **Reboot** – The kernel forced a reboot due to the recursive fault. 2. **Check dmesg** for earlier warnings about EDMA3, UART, or Bluetooth errors. 3. **Verify driver versions** – Ensure `fsl_edma3`, `lpuart`, and `hci_uart` drivers are up-to-date.
### Long-Term Fixes 1. **Update Kernel/Drivers**: - Check for upstream kernel fixes related to `fsl_edma3` and `lpuart`. - Apply any NXP/Freescale BSP patches for your SoC.
2. **Debugging Steps**: - Enable `CONFIG_DEBUG_VM` and `CONFIG_DEBUG_SPINLOCK` for more verbose error reporting. - Use `kdump` to capture a crash dump for deeper analysis. - Add `earlycon` to kernel cmdline for early boot logging.
3. **Code Review**: - Inspect `fsl_edma3_disable_request` for null pointer checks and proper locking. - Verify that UART/EDMA resources are properly cleaned up in reverse order of allocation. - Check for race conditions in `hci_uart_flush` and `lpuart_flush_buffer`.
4. **Workarounds**: - If using Bluetooth over UART, consider disabling EDMA for UART if not strictly needed. - Update `btattach` or Bluetooth stack to latest version. - Test with a different UART/Bluetooth configuration to isolate
Once again VulDB remains the best source for vulnerability data.