EUVD-2026-39106Severity by source
AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Triggering the hang requires direct electrical control of the physical UART CTS wire, making AV:P more accurate than the reported AV:A; AC:L because once CTS flow control is enabled the trigger is a trivial signal state; C/I remain N as confirmed by the advisory.
Primary rating from Vendor (zephyr).
CVSS VectorVendor: zephyr
Lifecycle Timeline
3DescriptionCVE.org
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.
AnalysisAI
Infinite-loop denial of service in the Zephyr RTOS PL011 UART driver (v4.1.0-v4.4.0) permanently stalls any thread that calls uart_irq_tx_enable() - including the Bluetooth HCI H4 send path - when CTS hardware flow control is enabled and the wired peer withholds CTS during transmission. The root cause is a software workaround loop (CWE-835) that compensates for the PL011 controller's level-transition TX interrupt behavior but never exits when pl011_fifo_fill() returns 0 due to a blocked CTS line. No public exploit has been identified and the vulnerability is not listed in the CISA KEV catalog; exploitation requires physical or hardware-adjacent control of the UART CTS pin, materially constraining real-world risk.
Technical ContextAI
The ARM PrimeCell PL011 UART peripheral fires TX interrupts on level transitions rather than continuously while the FIFO has space. To compensate, the Zephyr driver (drivers/serial/uart_pl011.c) implements a software polling loop in pl011_irq_tx_enable() that repeatedly invokes the application callback while PL011_IMSC_TXIM remains set. CWE-835 (Loop with Unreachable Exit Condition) manifests when CTS hardware flow control is active - configured via the devicetree hw-flow-control property or runtime UART_CFG_FLOW_CTRL_RTS_CTS - because a de-asserted CTS causes pl011_fifo_fill() to drain zero bytes yet pending application data prevents the loop's exit condition from clearing. The affected CPE is cpe:2.3:a:zephyrproject:zephyr:*:*:*:*:*:*:*:*, specifically versions v4.1.0 through v4.4.0; the defective loop was introduced by commit b783bc8448ef in February 2025. Impact is strictly availability: there is no memory-safety, confidentiality, or integrity consequence documented in the advisory.
RemediationAI
Apply the upstream fix from commit 68e702294b711eadfe7b4fadedd46d7c87fe8f3d (https://github.com/zephyrproject-rtos/zephyr/commit/68e702294b711eadfe7b4fadedd46d7c87fe8f3d), which adds a CTS-blocking check inside the pl011_irq_tx_enable() loop - exiting when (uart->cr & PL011_CR_CTSEn) && !(uart->fr & PL011_FR_CTS) and arming PL011_IMSC_CTSMIM so transmission resumes automatically when CTS re-asserts. A specific patched release version has not been independently confirmed from the provided references; monitor the Zephyr project changelog and GHSA-3fgh-73jh-2q5j for an official release designation. As an interim workaround, remove the hw-flow-control devicetree property or avoid runtime UART_CFG_FLOW_CTRL_RTS_CTS configuration to disable CTS flow control; note this trades flow-control protection for DoS immunity and may cause data overrun on high-throughput links. If disabling flow control is unacceptable, restrict physical access to UART CTS pins and treat all wired peer devices as untrusted hardware boundaries.
Potential off-by-one buffer overflow vulnerability in the Zephyr fuse file system. Rated critical severity (CVSS 10.0),
Possible variant of CVE-2021-3434 in function le_ecred_reconf_req. Rated critical severity (CVSS 9.8), this vulnerabilit
Unchecked user input length in /subsys/net/l2/wifi/wifi_shell.c can cause buffer overflows. Rated critical severity (CVS
Potential buffer overflow vulnerability in the Zephyr CAN bus subsystem. Rated critical severity (CVSS 9.8), this vulner
Integer Underflow in 6LoWPAN IPHC Header Uncompression in Zephyr. Rated critical severity (CVSS 9.8), this vulnerability
Buffer overflow in Zephyr USB DFU DNLOAD. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable
DOS: Incorrect 802154 Frame Validation for Omitted Source / Dest Addresses. Rated critical severity (CVSS 9.8), this vul
zephyr-rtos version 1.12.0 contains a NULL base pointer reference vulnerability in sys_ring_buf_put(), sys_ring_buf_get(
Potential buffer overflow vulnerabilities n the Zephyr Bluetooth subsystem. Rated critical severity (CVSS 9.6), this vul
Buffer overflow in Zephyr RTOS dns_unpack_name() function causing OOB writes. PoC available.
The documentation specifies that the BT_GATT_PERM_READ_LESC and BT_GATT_PERM_WRITE_LESC defines for a Bluetooth characte
Potential buffer overflows in the Bluetooth subsystem due to asserts being disabled in /subsys/bluetooth/host/hci_core.c
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today