CVE-2026-10642: Zephyr PL011 UART Infinite Loop Denial of Service (CWE-835)

Technical summary

The vulnerability resides in the pl011_irq_tx_enable() function within drivers/serial/uart_pl011.c. The function implements a workaround for the PL011 UART controller's level-transition TX-interrupt behavior by looping while the TX interrupt mask (PL011_IMSC_TXIM) is set and repeatedly invoking the application callback. However, when hardware flow control is active and the peer de-asserts CTS, the TX FIFO stops draining. The pl011_fifo_fill() function then returns 0 on each iteration while pending data remains unflushed, so the TX interrupt is never disabled—the loop condition never clears. This causes an unbounded spin in the calling thread's execution context (CWE-835: Infinite Loop). The flaw was introduced in commit b783bc8448ef in February 2025 and shipped in v4.1.0–v4.4.0. The fix breaks the loop when CTS is blocking and arms the CTS modem-status interrupt to resume transmission upon CTS reassertion.

Business impact

This vulnerability disrupts any Zephyr-based system relying on serial protocols over affected UART configurations. Bluetooth HCI stacks (e.g., h4_send() in the HCI H4 driver) are directly affected, freezing wireless stacks and rendering devices non-responsive. Real-time embedded systems and IoT devices cannot tolerate thread hangs; a single attacker-triggered hang in the UART driver can cascade through the entire device, preventing normal operation, breaking wireless connectivity, or forcing a reboot. Devices with external or removable serial modules (such as off-board Bluetooth controllers) face elevated risk because an attacker can physically intercept or spoof the CTS signal.

Affected systems

Zephyr RTOS releases v4.1.0, v4.2.0, v4.3.0, and v4.4.0 are affected when the PL011 UART driver is used with hardware flow control (CTS/RTS) enabled. The vulnerability is activated only when: (1) the PL011 UART is configured with hw-flow-control in the device tree or via runtime UART_CFG_FLOW_CTRL_RTS_CTS setting, and (2) the connected peer device withholds or de-asserts CTS during transmission. Systems without hardware flow control enabled, or using other UART drivers (e.g., NSIM, NXP, STMicroelectronics variants), are unaffected.

Exploitability

Exploitability requires physical or adjacent access to the UART's CTS signal line. An attacker controlling or spoofing the peer device on a CTS-enabled UART link can withhold CTS at will, triggering an indefinite spin in the TX-enable routine. The attack requires no user interaction, authentication, or special privileges; it is deterministic and repeatable. Attack surface is highest for systems with external or removable modules (e.g., off-board Bluetooth chips on a debug header, USB-to-serial adapters, or cellular modems). On-board permanently-soldered components present lower risk unless the attacker has direct physical board access. The CVSS vector AV:P (Physical) was assigned conservatively; however, the advisory flags that systems with removable/external serial peers (classified as Adjacent under AV:A) should have their specific deployments reviewed by the security team.

Remediation

Update Zephyr RTOS to the patched release (v4.5.0 or later—verify against the official Zephyr security advisory for exact version). The patch modifies pl011_irq_tx_enable() to check CTS status before entering the loop; if CTS is blocking, the routine breaks out and arms the CTS modem-status interrupt rather than spinning. When CTS re-asserts, the interrupt handler resumes transmission. For systems unable to patch immediately, disable hardware flow control (hw-flow-control = <0> in device tree) if the serial peer does not require it, or implement a timeout wrapper around uart_irq_tx_enable() calls as a temporary mitigation—though this is not a substitute for patching.

Patch guidance

Apply the official Zephyr patch from the security advisory corresponding to your release branch. The fix is integrated into v4.5.0 and later. Backports may be available for earlier LTS branches; check the Zephyr security advisories and release notes. After patching, rebuild and redeploy the firmware image. Test serial communication, particularly Bluetooth HCI and any other subsystems relying on the PL011 UART, to confirm CTS flow control works as expected.

Detection guidance

Monitor for thread hangs or watchdog resets involving UART driver components, particularly in contexts calling uart_irq_tx_enable() (e.g., h4_send() in Bluetooth). Kernel logs or debugger traces showing an indefinite loop in pl011_irq_tx_enable() or spin in uart_irq_tx_enable() are diagnostic. On live systems, inspect device tree or runtime UART configuration to determine if hw-flow-control is enabled on any PL011 instances. Audit serial peer devices (Bluetooth modules, modems, etc.) for any anomalies in CTS signal behavior; CTS de-assertion without corresponding data activity may indicate an attack or device failure. Network packet captures or Bluetooth traffic logs may show sudden cessation of activity corresponding to a hang event.

Why prioritize this

Although CVSS severity is rated MEDIUM (4.6), prioritization should be elevated for Zephyr deployments with external or removable UART peer devices, particularly Bluetooth HCI systems. The hang is deterministic, requires minimal attacker capability (adjacent access to a CTS line), and causes complete denial of service to the transport layer. Real-time systems and wireless IoT devices cannot tolerate indefinite thread stalls. Conversely, systems with only on-board permanent serial components and no hardware flow control enabled face significantly lower risk and may be deprioritized accordingly.

Risk score, explained

The CVSS 3.1 score of 4.6 (MEDIUM) reflects: (1) Physical/Adjacent Attack Vector—the attacker must have wired access to the CTS signal, (2) High Availability Impact—the hang completely disrupts the UART and dependent subsystems, but (3) No Confidentiality or Integrity impact—the vulnerability does not leak or corrupt data. The low base score reflects the narrow attack surface and lack of memory-safety consequences. However, in deployments with removable or externally-controlled serial modules, the practical risk may exceed this base score, warranting context-specific risk assessment.

Frequently asked questions