CVE-2026-10642
MediumCVSS 4.6Exploitation Probability (EPSS)
Low risk6th percentile - higher than 6% of all known CVEs
Summary
The Zephyr PL011 UART driver (drivers/serial/uart_pl011.c) has an unbounded loop in pl011_irq_tx_enable() that hangs the thread when CTS hardware flow control is enabled and the peer de-asserts CTS. The loop never exits because the TX FIFO cannot drain, causing a denial of service (CWE-835).
Risk Assessment
An attacker controlling the device on the UART CTS line can trigger the hang by withholding CTS during transmission, stalling the transport (e.g., Bluetooth HCI H4). This results in a denial of service with no impact on confidentiality or integrity.
Recommendation
Update Zephyr OS to a version containing the fix (commit after b783bc8448ef) that breaks the loop when CTS is blocking and arms the CTS modem-status interrupt to resume transmission when CTS re-asserts.
Other vulnerabilities in Zephyr OS
See all- CVE-2026-13216Medium
The virtio PCI driver in Zephyr OS (drivers/virtio/virtio_pci.c) improperly validates the capability length (cap_len) read from PCI configuration space. The lack of runtime validation (assert is disabled in production builds) leads to an out-of-bounds write on the kernel stack during device initialization.
- CVE-2026-11809Low
The UpdateHub OTA client in Zephyr OS contains an uninitialized heap memory read and out-of-bounds read in z_impl_updatehub_probe(). A malicious UpdateHub server can send a crafted response that, after a failed first JSON parse, uses a non-NUL-terminated metadata_copy buffer, leading to a read past the allocated memory and potentially crashing the device.
- CVE-2026-11368High
A vulnerability in the ATT layer of the Bluetooth stack in Zephyr OS leads to a use-after-free of channel memory. When a remote device disconnects during ongoing ATT traffic, a deferred callback may reference a freed channel, causing a system crash or potential memory corruption.
- CVE-2026-10677Medium
In Zephyr OS (versions v1.12.0 through v4.4.1), the CONFIG_USERSPACE syscall verifier in z_vrfy_k_poll() does not free memory on validation failure. An attacker can repeatedly trigger a memory leak, exhausting the kernel pool and causing denial of service.
- CVE-2026-10674Medium
In Zephyr OS (since v2.5.0), the NXP LPUART driver disables peripheral clocks before validating configuration. Unsupported parameters cause an error without re-enabling the clock, leading to a hard fault and system crash.
- CVE-2026-10666High
A stack buffer overflow vulnerability exists in the parse_ipv4() function in Zephyr OS. An attacker can craft an IP address with a long suffix after the colon, causing data to be copied beyond the allocated 17-byte buffer. The issue has been present since v1.9.0 through v4.4.0 and can lead to system crashes or potential control-flow hijack.
- CVE-2026-10657Low
In Zephyr OS, a vulnerability in the DNS resolver uses memcmp() to always compare 7 bytes with the ".local" suffix, even when the final hostname label is shorter. This causes an out-of-bounds read past the string terminator, potentially leading to a page fault and denial of service (DoS). The flaw is present only when CONFIG_MDNS_RESOLVER is enabled and exists since v1.10.0.
- CVE-2026-10656Medium
The MAX32xxx USB device controller driver (udc_max32.c) in Zephyr OS does not check if the endpoint buffer is NULL in the OUT and IN transfer-completion handlers. When a USB host sends a new SETUP packet during an ongoing EP0 transfer, the FIFO can be drained, causing a stale event to be processed, leading to a near-NULL pointer dereference and device crash.
- CVE-2026-10648Medium
In Zephyr OS, the mcumgr_serial_process_frag() function calls net_buf_reset() on the result of smp_packet_alloc() before checking for NULL. When the MCUmgr packet pool (default 4 buffers) is exhausted, smp_packet_alloc() returns NULL, and writing through the NULL pointer causes a system crash.
Original NVD description (English source)
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. Because that peer is the device wired to the UART — which may be a removable or external module (e.g. an off-board Bluetooth controller on the HCI H4 link) rather than a permanently-bonded on-PCB part — the attack vector is scored Adjacent (AV:A) rather than Physical; the security subcommittee should confirm the vector against the specific deployment. 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.