ZephyrProject Zephyr up to 4.3.1/4.4.x SCI UART Driver uart_renesas_ra_sci.c uart_ra_sci_eri_isr user_cb improper synchronization

Summaryinfo

A vulnerability identified as critical has been detected in ZephyrProject Zephyr up to 4.3.1/4.4.x. Affected is the function uart_ra_sci_eri_isr of the file drivers/serial/uart_renesas_ra_sci.c of the component SCI UART Driver. The manipulation of the argument user_cb leads to improper synchronization. This vulnerability is documented as CVE-2026-90585. The attack needs to be performed locally. There is not any exploit available. You should upgrade the affected component.

Detailsinfo

A vulnerability was found in ZephyrProject Zephyr up to 4.3.1/4.4.x. It has been rated as critical. This issue affects the function uart_ra_sci_eri_isr of the file drivers/serial/uart_renesas_ra_sci.c of the component SCI UART Driver. The manipulation of the argument user_cb with an unknown input leads to a improper synchronization vulnerability. Using CWE to declare the problem leads to CWE-662. The product utilizes multiple threads, processes, components, or systems to allow temporary access to a shared resource that can only be exclusive to one process at a time, but it does not properly synchronize these actions, which might cause simultaneous accesses of this resource by multiple threads or processes. Impacted is availability. The summary by CVE is:

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.

The advisory is shared at github.com. The identification of this vulnerability is CVE-2026-90585 since 09/12/2026. The exploitation is known to be easy. An attack has to be approached locally. Technical details are known, but no exploit is available.

Upgrading to version 4.3.2 or 4.5.0 eliminates this vulnerability.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Productinfo

Type

• Project Management Software

Vendor

• ZephyrProject

Name

• Zephyr

Version

• 4.0
• 4.1
• 4.2
• 4.3
• 4.3.0
• 4.3.1
• 4.4

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion