CVE-2026-90585
MediumCVSS 4.6Summary
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- CVE-2026-87043Medium
In the entropy-device random number generator (subsys/random/random_entropy_device.c), rand_get() returned early with -ENODEV when device_is_ready() failed, bypassing the non-cryptographic system-timer fallback. Because sys_rand_get() and sys_rand32_get() return void and cannot report failure, the caller's output buffer was left untouched and its previous (uninitialized) contents were returned as random data. The not-ready state is a normal runtime condition (e.g., early initialization) or a permanent result of an entropy driver init failure.
- CVE-2026-87041High
A vulnerability in the RTIO submission-queue verifier rtio_vrfy_sqe() in Zephyr RTOS stems from incorrectly combining K_SYSCALL_MEMORY() results with &=; since the macro returns nonzero on failure, buffer permission checks were inverted. Inaccessible buffers were accepted while legitimate thread-owned buffers caused a kernel oops. This allows user threads with an RTIO context to write to arbitrary kernel memory, disclose it, or fault the kernel, bypassing CONFIG_USERSPACE isolation.
- CVE-2026-87039High
A vulnerability in the Zephyr RTOS syscall verifier z_vrfy_i2s_configure() skips the K_SYSCALL_OBJ ownership/type check for config.mem_slab and the block_size sanity check when frame_clk_freq is 0. As a result, an unprivileged thread under CONFIG_USERSPACE can supply an arbitrary pointer that reaches driver code (e.g., i2s_litex) and is used in supervisor context by k_mem_slab_alloc()/k_mem_slab_free().
- CVE-2026-16511High
Two RTIO syscall verifiers in Zephyr RTOS failed to properly validate user-supplied pointers before the kernel wrote through them. z_vrfy_rtio_sqe_cancel() performed no validation at all, allowing a user-mode thread to set chosen bits in kernel memory, while z_vrfy_rtio_sqe_copy_in_get_handles() wrote a kernel pointer to an arbitrary address without a write-permission check. Only systems built with CONFIG_USERSPACE and CONFIG_RTIO are affected.
- CVE-2026-82962Medium
A vulnerability in ethernet_fill_header() in the Zephyr RTOS network stack prepends the Ethernet header in place via net_buf_push without verifying that the packet has sufficient headroom. Packets allocated by a different L2 (e.g., 802.15.4/OpenThread, PPP) and handed to Ethernet through routing or tunnelling have too little (usually zero) headroom, causing an out-of-bounds write. In builds without CONFIG_ASSERT and CONFIG_NET_BUF_HARDENING this results in memory corruption.
- CVE-2026-19595Medium
A vulnerability in the Zephyr RTOS syscall verifier: z_vrfy_rtio_cqe_get_mempool_buffer() validated its output parameters buff and buff_len with K_SYSCALL_MEMORY_READ() instead of K_SYSCALL_MEMORY_WRITE(). This allows an unprivileged user-mode thread to invoke the syscall with pointers to read-only memory, causing a supervisor-mode store outside the permitted region or a kernel fault that halts or reboots the device.
- CVE-2026-19940Medium
A vulnerability in the Bluetooth Classic Hands-Free Profile Audio Gateway (HFP AG) implementation in Zephyr RTOS causes corruption of the kernel timeout list. By sending AT+CIND? and quickly reconnecting, a remote attacker can trigger a system-wide fault or hang.
- CVE-2026-19736High
The NXP MCUX TRNG entropy driver in Zephyr (drivers/entropy/entropy_mcux_trng.c) passes the caller's byte count directly to the SDK routine TRNG_GetRandomData(), which on i.MX RT5xx/RT6xx parts always copies whole 32-bit words and rounds entropy draws up to a multiple of 128 bytes. A request length not a multiple of four causes an underflow in the SDK's buffer-full check, leading to an overflow of up to 127 bytes past the caller's buffer.
- CVE-2026-19575High
A vulnerability in Zephyr RTOS affects the user-mode verification handler z_vrfy_device_deinit() in kernel/device.c, which validated its dev argument with K_SYSCALL_OBJ_INIT(dev, K_OBJ_ANY). Because k_object_validate() short-circuits type comparison for K_OBJ_ANY, the check only verified that the pointer was the base address of some kernel object the calling thread was granted, without comparing the object's actual type. This allows a local user-mode thread to pass a thread stack object (e.g., from k_thread_stack_alloc()) and achieve supervisor-mode kernel code execution.
- CVE-2026-19574High
In the ARM64 MMU back-end of Zephyr RTOS, address space identifiers (ASIDs) are assigned by a bare round-robin counter, which after wrapping past 255 possible values can hand the same ASID to a new domain while a still-live domain holds it. Because domain-private mappings are installed as non-global (MT_NG), the ASID is the only tag separating cached translations in the TLB, and the context-switch path does not flush the TLB for a duplicate reached through a third domain. As a result, user-mode threads in one domain can read and write memory belonging to another domain, defeating memory-domain isolation.
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

