Zephyr RTOS EUVD-2026-60266

Three conditions must all be true simultaneously: (1) Hardware - the target system uses an ARM SoC with a PL011 UART peripheral running Zephyr 1.14.0 through 4.4.1; (2) Configuration - the application explicitly calls uart_irq_err_enable() on the relevant UART port in interrupt-driven mode; this is off by default and no in-tree Zephyr driver or subsystem enables it, so only custom application code can trigger this path; (3) Physical access - the attacker controls the serial peer connected to that UART port and can inject line-level errors (baud mismatch for framing error, inverted parity bit for parity error, mid-character voltage transition for break error, or sustained FIFO flooding for overrun error). Exploitation is limited by: the non-default uart_irq_err_enable() requirement (the single largest filter), physical proximity to the UART hardware interface, the absence of any confidentiality or code-execution impact (pure availability DoS), and the restriction to Zephyr - not Linux or other OS PL011 drivers.

The CVSS 4.6 score and AV:P (physical) vector accurately reflect the real-world risk profile. The physical access requirement is meaningful: the attacker must control the serial peer device - physically attached to the UART header, plugged in as a removable serial adapter, or acting as the other end of a wired serial link. This is not a remotely exploitable vulnerability over a network. The most significant limiting factor is the non-default configuration gate: uart_irq_err_enable() must be explicitly called by application code, and no in-tree Zephyr subsystem calls it, so the overwhelming majority of Zephyr deployments are unaffected by this issue even if they run on PL011 hardware. The impact ceiling is high availability (permanent CPU hang) with zero confidentiality or integrity impact. No KEV listing and no EPSS data were provided, consistent with a low-exploitation-urgency finding. Overall this is a genuine but narrow vulnerability: high severity within its specific configuration window, but that window covers a small fraction of real deployments.

An attacker with physical access to the UART serial interface of a Zephyr device - for example, via a UART-to-USB adapter connected to an exposed debug header - transmits a baud-rate-mismatched signal or asserts a mid-character break to trigger a framing or break error on the RX line. If the target application has called uart_irq_err_enable(), the PL011 hardware sets the error interrupt bit in MIS, pl011_isr() fires but never writes UARTICR to clear it, the interrupt line stays asserted, and the CPU enters a permanent ISR re-entry loop, hanging the system with no recovery. No public POC is available, but the technique is mechanically straightforward for any attacker with physical serial access.