CVE-2026-10642
MediumCVSS 6.5Exploitation Probability (EPSS)
Low risk7th percentile — higher than 7% of all known CVEs
Summary
The Zephyr PL011 UART driver (drivers/serial/uart_pl011.c) has an unbounded loop in pl011_irq_tx_enable() that hangs the calling thread when CTS hardware flow control is enabled and the peer de-asserts CTS. The loop never exits because the TX FIFO cannot drain, causing a denial of service (CWE-835).
Risk Assessment
An attacker controlling the device on the UART CTS line can trigger a permanent hang of the transmission thread (e.g., Bluetooth HCI H4 driver), disrupting system availability without affecting confidentiality or integrity.
Recommendation
Update Zephyr OS to a version containing the fix (commit after b783bc8448ef) that breaks the loop on CTS blockage and arms the CTS modem-status interrupt to resume transmission when CTS re-asserts.
Original NVD description (English source)
The Zephyr PL011 UART driver (drivers/serial/uart_pl011.c) contains an unbounded software loop in pl011_irq_tx_enable() that repeatedly invokes the interrupt-driven application callback while the TX interrupt mask bit (PL011_IMSC_TXIM) is set, to work around the controller's level-transition TX-interrupt behavior. When CTS hardware flow control is enabled (devicetree hw-flow-control or runtime UART_CFG_FLOW_CTRL_RTS_CTS) and the wired serial peer de-asserts CTS, the controller stops draining the TX FIFO; pl011_fifo_fill() then returns 0 on every call while the application still has pending data and therefore never disables the TX interrupt. The loop condition never clears, so the thread that called uart_irq_tx_enable() (e.g. h4_send() in the Bluetooth HCI H4 driver) spins indefinitely, hanging the executing context and stalling the transport — a denial of service (CWE-835). An attacker controlling the device attached to the UART's CTS line can trigger the hang by withholding CTS during transmission. Impact is availability only; there is no memory-safety, confidentiality, or integrity consequence. The vulnerable loop was introduced in commit b783bc8448ef (Feb 2025) and shipped in releases v4.1.0 through v4.4.0. The fix breaks out of the loop when CTS is blocking and arms the CTS modem-status interrupt to resume transmission when CTS re-asserts.