Skip to main content
← Vulnerabilities

Renesas RA SCI UART driver: unacknowledged receive-error interrupt causes a permanent interrupt storm and CPU lockup

4.6MediumCNA
Exploited
No known exploitation
Fix
Fixed in 4.3.2, 4.5.0
Who is exposed
Not reported

Do first: Upgrade to a fixed version: 4.3.2, 4.5.0.

Published
Last modified
5/100 · provisional
None on Exploit-DB, Metasploit or GitHub

Summary

Zephyr's Renesas RA SCI UART driver can be locked up by an attacker with physical access to the serial link, who needs no login or user action. A single receive error, such as a break or a frame at a mismatched baud rate, leaves the error interrupt firing endlessly and captures the CPU until an external reset or hardware watchdog intervenes, causing denial of service only.

Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.

Read the original description

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.

cve.now Index

5Pcve.now Index 5 of 100 · methodology v3 · provisional
  • Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
  • Exposure?/25Unknown. No advisory context yet
  • Reach?/20Unknown. No tracked technology or package matched
  • Severity4.6/10CVSS 4.6
  • No patch0/5No signal

What would change the score

  • Would score about 60 if added to CISA KEV
  • Would score about 55 if CISA's SSVC rates exploitation active
  • Would score about 27 if advisories confirm default setups are exposed

What to do

  • Upgrade to a fixed version: 4.3.2, 4.5.0.

Timeline

  1. CVE published
  2. First seen by cve.now

Affected versions

  • zephyr

    From 4.0.0 · fixed in 4.3.2; From 4.4.0 · fixed in 4.5.0

Evidence 2

  1. Advisory
  2. Patch

Corrections

None so far.

Something wrong on this page? Report an error. Every fix is listed here.

Questions about CVE-2026-90585

Is CVE-2026-90585 being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data

Which versions are affected by CVE-2026-90585?

zephyr: from 4.0.0 before 4.3.2; from 4.4.0 before 4.5.0.Source: cve.now feed data

How do I fix CVE-2026-90585?

Upgrade to a fixed version: 4.3.2, 4.5.0.Source: cve.now feed data