CVE Catalog

CVE-2026-90585

MediumCVSS 4.6
Published: Updated: Translated: NVD NIST

Summary

The Renesas RA SCI UART driver in Zephyr does not acknowledge the receive-error condition in uart_ra_sci_eri_isr() when no callback is registered (data->user_cb is NULL). The SCI error flags remain set and the ICU interrupt flag is never cleared, causing the ISR to re-pend immediately and re-enter endlessly. This occurs with CONFIG_UART_INTERRUPT_DRIVEN=y and CONFIG_UART_ASYNC_API=n when the error interrupt is unmasked by uart_configure() or uart_irq_err_enable().

Risk Assessment

An ordinary receive line error (overrun, framing, parity, or break) triggered by the peer device hangs the entire system, as the CPU is trapped in the re-entering ISR and never returns to thread context. Impact is availability only — an external reset or hardware watchdog is required; there is no memory corruption or information disclosure.

Recommendation

Update Zephyr to a version containing the uart_renesas_ra_sci driver fix that acknowledges the error condition and clears the interrupt flags regardless of callback registration. Until then, avoid calling uart_configure() and uart_irq_err_enable() on instances used with the polling API or without a registered callback.

Other vulnerabilities in Zephyr RTOS

See all
Original NVD description (English source)

The Renesas RA SCI UART driver's receive-error ISR, uart_ra_sci_eri_isr() in drivers/serial/uart_renesas_ra_sci.c, acknowledged the error condition only when a Zephyr interrupt-driven callback had already been registered. With CONFIG_UART_INTERRUPT_DRIVEN=y and CONFIG_UART_ASYNC_API=n, if data->user_cb 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 R_ICU->IELSR_b[eri_irq].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 uart_ra_sci_init(), but FSP's R_SCI_UART_Open() unconditionally re-enables it, and uart_ra_sci_configure() - the back end of the public uart_configure() API, enabled by default via CONFIG_UART_USE_RUNTIME_CONFIGURE - performs a Close()/Open() pair without re-masking it. Any runtime uart_configure() therefore leaves the error interrupt live regardless of whether a callback has been set, as does calling uart_irq_err_enable() on its own. An instance used with the polling API, or the window between uart_configure() and uart_irq_callback_user_data_set(), 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 sci_uart_eri_isr() clears both the error flags and the pending IRQ.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS