Description
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.
Published: 2026-06-24
Score: 6.5 Medium
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Pl011 UART driver in Zephyr contains an unbounded loop in pl011_irq_tx_enable() that repeatedly calls the interrupt‑driven callback as long as the TX interrupt mask remains set. When CTS hardware flow control is active and the peer de‑asserts CTS, the controller stops draining the FIFO, causing pl011_fifo_fill() to return zero and the loop condition never to clear. As a result, the calling thread spins indefinitely, hanging the execution context and stalling the transport, achieving a classic denial‑of‑service condition. The flaw is purely an availability issue; it does not affect memory safety, confidentiality, or integrity.

Affected Systems

This vulnerability affects Zephyr RTOS releases from v4.1.0 through v4.4.0, inclusive. The flaw was introduced in a February 2025 commit and is present in all builds that include the affected code without the later patch.

Risk and Exploitability

The CVSS score of 6.5 indicates moderate severity, and EPSS data is not available, so the current exploitation probability cannot be quantified. The flaw is not listed in the CISA KEV catalog. Exploitation requires an attacker who can control the UART's CTS line, which implies physical or low‑level access to the embedded system. Once CTS is de‑asserted during transmission, the driver will hang until CTS is re‑asserted, leading to a loss of availability for the affected UART channel.

Generated by OpenCVE AI on June 24, 2026 at 23:26 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade Zephyr to a version that includes the upstream fix (for example, any release beyond v4.4.0 that incorporates commit 68e702294b…); rebuild and flash the updated firmware.
  • If an upgrade is not possible, manually apply the patch changes from the referenced commit to the current Zephyr source tree and rebuild the system.
  • As a temporary mitigation, disable CTS‑based hardware flow control on UART interfaces that may be exposed to untrusted devices or ensure that the connected peer always keeps CTS asserted during operation.

Generated by OpenCVE AI on June 24, 2026 at 23:26 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 24 Jun 2026 21:45:00 +0000

Type Values Removed Values Added
Description 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.
Title Unbounded TX busy-loop DoS in Zephyr PL011 UART driver under CTS hardware flow control
Weaknesses CWE-835
References
Metrics cvssV3_1

{'score': 6.5, 'vector': 'CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}


Subscriptions

No data.

cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-06-24T21:32:05.251Z

Reserved: 2026-06-02T15:11:43.570Z

Link: CVE-2026-10642

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-06-24T23:30:03Z

Weaknesses
  • CWE-835

    Loop with Unreachable Exit Condition ('Infinite Loop')