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
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
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. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires both of the following conditions simultaneously: (1) CTS hardware flow control must be enabled on the PL011 UART instance, configured either statically via the devicetree hw-flow-control property or dynamically at runtime via UART_CFG_FLOW_CTRL_RTS_CTS - this is not the default in many Zephyr configurations; and (2) the attacker must be able to de-assert the CTS signal on the physical UART CTS pin, either by controlling the wired peer device directly or by compromising firmware on that device. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The reported CVSS 3.1 score of 6.5 uses vector AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, but the Adjacent-Network designation merits scrutiny: triggering the hang requires direct electrical control of the UART CTS hardware line, which is arguably an AV:P (Physical) scenario rather than a network-adjacent one. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An attacker who has physical control of - or has compromised - a device wired to the UART CTS pin of a Zephyr v4.1.0-v4.4.0 system (for example, a Bluetooth module connected via HCI H4 over UART with CTS flow control enabled) simply holds the CTS line de-asserted while the Zephyr host initiates a transmission. The pl011_irq_tx_enable() loop spins indefinitely, permanently blocking the transmitting thread and stalling the UART transport layer; no exploit code or elevated privilege is required beyond physical or logical control of the CTS signal. |
| Remediation | 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. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
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