CVE-2026-10642: Zephyr PL011 UART Driver DoS Vulnerability

CVE-2026-10642 Overview

CVE-2026-10642 is a denial-of-service vulnerability in the Zephyr RTOS PL011 UART driver (drivers/serial/uart_pl011.c). The flaw is an unbounded software loop in pl011_irq_tx_enable() that spins indefinitely when CTS (Clear To Send) hardware flow control is enabled and the wired peer de-asserts CTS during transmission. An attacker who controls the device attached to the UART's CTS line can withhold CTS to hang the calling thread, stalling transports such as the Bluetooth HCI H4 driver. Impact is restricted to availability — there is no memory-safety, confidentiality, or integrity consequence. The vulnerable code was introduced in commit b783bc8448ef (February 2025) and shipped in Zephyr releases v4.1.0 through v4.4.0.

Critical Impact
A peer device on the UART link can permanently hang the executing thread by withholding CTS, producing a transport-level denial of service [CWE-835].

Affected Products

Zephyr RTOS v4.1.0
Zephyr RTOS v4.2.0 through v4.3.x
Zephyr RTOS v4.4.0 (PL011 UART driver with CTS hardware flow control enabled)

Discovery Timeline

2026-06-24 - CVE-2026-10642 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-10642

Vulnerability Analysis

The Zephyr PL011 UART driver implements a software workaround for the controller's level-transition TX interrupt behavior. In pl011_irq_tx_enable(), the driver repeatedly invokes the interrupt-driven application callback while the TX interrupt mask bit PL011_IMSC_TXIM is set. The loop is expected to terminate once the application disables the TX interrupt after draining its pending data.

When CTS hardware flow control is active and the remote peer de-asserts CTS, the PL011 controller stops draining the TX FIFO. pl011_fifo_fill() consequently returns 0 on every invocation because the FIFO never has room consumed. The application callback observes that it still has pending data, so it never clears PL011_IMSC_TXIM. The loop condition never resolves and the thread spins forever.

Any caller of uart_irq_tx_enable() — for example h4_send() in the Bluetooth HCI H4 transport — becomes wedged in the driver, stalling that transport entirely.

Root Cause

The root cause is a missing exit condition for the CTS-blocked state. The loop relies on the application callback to disable the TX interrupt, but the callback cannot make forward progress while the hardware refuses to drain the FIFO. The driver does not check the PL011_FR_CTS flag or arm the CTS modem-status interrupt to break the wait, producing a classic loop-with-unreachable-exit condition [CWE-835].

Attack Vector

Exploitation requires adjacent access — specifically, control of the device wired to the UART's CTS line. The attacker simply holds CTS de-asserted while the Zephyr device attempts to transmit. No authentication, privileges, or user interaction are required. The result is a hang of the calling thread and stall of the UART transport, including any higher-level protocol such as Bluetooth HCI riding on it.

	 * uart_fifo_fill() is called with small amounts of data, the 1/8 TX
	 * FIFO threshold may never be reached, and the hardware TX interrupt
	 * will never trigger.
	 *
	 * Exit loop if CTS flow control is enabled and CTS is blocking
	 * transmission. CTS bit low means remote is not ready.
	 */
	while (uart->imsc & PL011_IMSC_TXIM) {
		/* If CTS flow control is enabled and CTS is blocking, exit loop */
		if ((uart->cr & PL011_CR_CTSEn) && !(uart->fr & PL011_FR_CTS)) {
			/* clear software flag to allow TX enable to be called again */
			data->sw_call_txdrdy = true;
			/* Enable CTS interrupt to resume when CTS clears */
			uart->imsc |= PL011_IMSC_CTSMIM;
			break;
		}
		K_SPINLOCK(&data->irq_cb_lock) {
			data->irq_cb(dev, data->irq_cb_data);
		}

Source: Zephyr fix commit 68e70229. The patch breaks out of the loop when CTS is asserted-low and enables PL011_IMSC_CTSMIM so transmission resumes via interrupt when CTS re-asserts.

Detection Methods for CVE-2026-10642

Indicators of Compromise

A Zephyr thread blocked indefinitely inside pl011_irq_tx_enable() with 100% CPU utilization in that context.
Bluetooth HCI H4 transport (or other UART consumer) stops processing commands while the device remains otherwise responsive on unrelated subsystems.
PL011 registers showing PL011_CR_CTSEn set and PL011_FR_CTS cleared for an extended duration during an active transmit.

Detection Strategies

Audit firmware builds for Zephyr versions v4.1.0 through v4.4.0 with hw-flow-control enabled in devicetree or UART_CFG_FLOW_CTRL_RTS_CTS configured at runtime.
Add watchdog instrumentation around UART transmit paths to flag threads that fail to yield within expected timeouts.
Review HCI transport telemetry for sudden, sustained transmit stalls correlated with CTS state changes on connected peripherals.

Monitoring Recommendations

Enable Zephyr kernel thread analyzer or stack/CPU sampling to detect threads pinned inside the PL011 driver.
Log CTS modem-status transitions on production devices where the UART peer is untrusted or physically accessible.
Track firmware version inventory for embedded fleets to identify deployments still on vulnerable Zephyr releases.

How to Mitigate CVE-2026-10642

Immediate Actions Required

Apply Zephyr commit 68e702294b711eadfe7b4fadedd46d7c87fe8f3d to drivers/serial/uart_pl011.c in any build derived from v4.1.0 through v4.4.0.
Inventory all firmware images using the PL011 UART driver with CTS flow control enabled and prioritize them for rebuild.
Validate the patched build by exercising the UART with a peer that holds CTS de-asserted during transmit and confirming the thread no longer hangs.

Patch Information

The fix is provided in the upstream Zephyr commit 68e702294b and documented in the Zephyr GHSA-3fgh-73jh-2q5j advisory. The patch breaks out of the TX enable loop when PL011_CR_CTSEn is set and PL011_FR_CTS is low, then arms PL011_IMSC_CTSMIM so the CTS modem-status interrupt resumes transmission when the peer re-asserts CTS.

Workarounds

Disable CTS hardware flow control on UART instances where the connected peer is untrusted or where the peer cannot be guaranteed to assert CTS reliably.
Restrict physical access to UART headers and CTS lines on deployed devices to reduce adjacent-network exposure.
Where flow control must remain enabled, isolate the calling thread so a transport stall does not block critical kernel paths, and add a software timeout that aborts pending transmits.

bash

# Devicetree example: disable hardware flow control on a PL011 UART node
# Remove or omit the hw-flow-control property until the patch is applied
&uart0 {
    status = "okay";
    current-speed = <115200>;
    /* hw-flow-control;  <-- remove this line as a temporary mitigation */
};