CVE-2026-90585: Renesas RA SCI UART driver: unacknowledged receive-error interrupt causes a permanent interrupt storm and CPU lockup
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.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to the lockup condition?
Affected deployments use the Renesas RA SCI UART driver with CONFIG_UART_INTERRUPT_DRIVEN=y and CONFIG_UART_ASYNC_API=n, while no interrupt-driven user callback is registered. The error interrupt must also be unmasked, which can occur after uart_configure() or after calling uart_irq_err_enable().
What must happen for exploitation to cause a denial of service?
A UART receive error must occur while the error interrupt is live and data->user_cb is NULL. The severity vector identifies the attack vector as physical, consistent with an attacker needing access to influence the relevant UART connection.
Is a callback-registration timing window affected?
Yes. The interval between uart_configure() and uart_irq_callback_user_data_set() can leave the error interrupt enabled with no callback installed. A UART instance used through the polling API can also be exposed when its error interrupt has been enabled.
What can be done if the update is not immediately available?
Avoid calling uart_configure() or uart_irq_err_enable() unless an interrupt-driven callback has already been registered. Where possible, keep the SCI error interrupt masked for UART instances that use polling or otherwise do not have a callback.
How can operators recognize an affected system?
The system can become CPU-locked after a UART receive error, with the receive-error ISR repeatedly re-entered. On affected hardware, the SCI SSR error flags and the ICU event flag remain set rather than being acknowledged and cleared.