UBUNTU-CVE-2026-90585: Medium severity ubuntu/zephyr vulnerability

The Renesas RA SCI UART driver's receive-error ISR, uartrascieriisr() in drivers/serial/uartrenesasrasci.c, acknowledged the error condition only when a Zephyr interrupt-driven callback had already been registered. With CONFIGUARTINTERRUPTDRIVEN=y and CONFIGUARTASYNCAPI=n, if data->usercb is NULL the ISR body is empty: the SCI error flags (SSR.ORER, SSR.FER, SSR.PER) are left set and the ICU event flag RICU->IELSRb[eriirq].IR is never cleared, so the interrupt re-pends immediately and the ISR is re-entered without end. The error interrupt is masked at boot by uartrasciinit(), but FSP's RSCIUARTOpen() unconditionally re-enables it, and uartrasciconfigure() - the back end of the public uartconfigure() API, enabled by default via CONFIGUARTUSERUNTIMECONFIGURE - performs a Close()/Open() pair without re-masking it. Any runtime uartconfigure() therefore leaves the error interrupt live regardless of whether a callback has been set, as does calling uartirqerrenable() on its own. An instance used with the polling API, or the window between uartconfigure() and uartirqcallbackuserdataset(), thus runs with the error interrupt unmasked and no callback registered. The trigger is an ordinary receive line error - overrun, framing, parity, or a break condition - which is fully determined by the device attached to the serial link. A peer able to assert a break or transmit at a mismatched baud rate produces such an error at will, so a single frame is enough to enter the state. The impact is availability only: the CPU is captured in the re-entering ISR and never returns to thread context, hanging the entire system until an external reset or hardware watchdog fires. There is no memory corruption or information disclosure. Builds using the asynchronous UART API are unaffected, because the fall-through to FSP's sciuarteriisr() clears both the error flags and the pending IRQ.