GHSA-p99p-qqr7-mqcx: 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 UART usage patterns are exposed to the interrupt storm?
Instances using the polling API are exposed when the error interrupt is unmasked and no interrupt-driven callback is registered. The window after uart_configure() and before uart_irq_callback_user_data_set() is also exposed, as is use of uart_irq_err_enable() without a callback.
Are default Zephyr settings sufficient to create the unsafe state?
CONFIG_UART_USE_RUNTIME_CONFIGURE enables the public uart_configure() path by default. When CONFIG_UART_INTERRUPT_DRIVEN=y and CONFIG_UART_ASYNC_API=n, calling uart_configure() performs a Close()/Open() sequence that leaves the error interrupt enabled even if no callback has been set.
What condition triggers the CPU lockup?
A UART receive error that sets an overrun, framing, or parity error flag can trigger it while the error interrupt is live and data->user_cb is NULL. In that state, the ISR does not clear either the SCI error flags or the ICU event flag, so the interrupt immediately re-pends.
How can teams identify potentially affected code paths?
Review Renesas RA SCI UART instances built with CONFIG_UART_INTERRUPT_DRIVEN=y and CONFIG_UART_ASYNC_API=n. Identify calls to uart_configure() or uart_irq_err_enable() that can occur before uart_irq_callback_user_data_set(), and instances intentionally used through the polling API.