CVE-2026-14696
MediumCVSS 6.5Exploitation Probability (EPSS)
Low risk10th percentile - higher than 10% of all known CVEs
Summary
A vulnerability in Zephyr RTOS causes network buffer (net_pkt) leaks when Ethernet bridging is enabled (CONFIG_NET_ETHERNET_BRIDGE). Frames with unrecognized EtherType that are also delivered to the local stack are marked as NET_OK, which is interpreted as consumed, but they are never freed. An attacker on the L2 segment can flood broadcast/multicast frames with arbitrary EtherType, exhausting the RX buffer pool and causing a persistent denial of service until reboot.
Risk Assessment
The risk is a remotely triggerable persistent denial of service (DoS) on devices with Ethernet bridging enabled. The attack requires no authentication and can be performed by any device on the L2 segment, preventing further traffic reception until reboot.
Recommendation
Apply the vendor-provided fix (Zephyr RTOS) immediately, which changes eth_bridge_handle_locally() to propagate the correct verdict and release packets properly. If the patch is not yet available, consider disabling Ethernet bridging or restricting trust to devices on the L2 segment.
Other vulnerabilities in Zephyr RTOS
See all- 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.
- CVE-2026-19569High
A vulnerability in the Zephyr RTOS kernel allows an unprivileged user-mode thread to perform an out-of-bounds write in kernel memory. It stems from missing overflow checks when calculating allocation sizes for dynamic kernel objects, leading to undersized heap allocations. An attacker can exploit this to escalate privileges and execute arbitrary code at the kernel level.
- CVE-2026-19185High
A vulnerability was found in the system-call verifier for i3c_do_ccc() in Zephyr RTOS, which fails to validate per-target data pointers in the i3c_ccc_payload structure. The verifier also operates on the caller's live structure, allowing another thread to modify fields between check and use. This allows an unprivileged thread to write to arbitrary kernel addresses (via read CCC) or disclose kernel memory (via write CCC), leading to privilege escalation.
- CVE-2026-18747Medium
A vulnerability in the SMP-over-console transport in Zephyr RTOS allows an unauthenticated attacker to trigger a buffer length underflow by sending a single 7-byte frame to the management console. This leads to an out-of-bounds read, potentially causing a denial of service on the MCUmgr thread or memory disclosure.
- CVE-2026-18417Medium
In Zephyr RTOS, a vulnerability exists in the BSD socket layer where an asynchronous error was stored in the user_data field of the network context, which for listening TCP sockets is used to store a pointer to the parent context. In v4.3.0, after an interface-down event, the accept callback was not disarmed, leading to reuse of the poisoned value as a pointer and writes to an invalid address, causing a kernel fatal error (device crash or reset).
Original NVD description (English source)
When Ethernet bridging is enabled (CONFIG_NET_ETHERNET_BRIDGE), eth_bridge_input_process() in subsys/net/l2/ethernet/bridge/bridge_input.c decides how each frame received on a bridge member interface is handled. For frames that must also be delivered to the local stack, the code called eth_bridge_handle_locally() and returned NET_OK. That helper does not consume the packet — it only calls bridge_iface_recv() (via virtual_recv()), which returns NET_CONTINUE without taking ownership of pkt. The NET_OK verdict then propagates through ethernet_recv() up to processing_data() in subsys/net/ip/net_core.c, where NET_OK is interpreted as "the packet was consumed, do not free it." Because no consumer actually took ownership, the RX net_pkt is never returned to the pool and is leaked. The concretely reproducible leak occurs for frames whose EtherType has no registered L3 handler when CONFIG_NET_ETHERNET_FORWARD_UNRECOGNISED_ETHERTYPE is set (default y when CONFIG_NET_SOCKETS_PACKET is enabled): the fall-through L3 dispatch does not overwrite the NET_OK verdict, so ethernet_recv() returns NET_OK and the buffer is never released. Any device on a bridged L2 segment can emit broadcast/multicast frames carrying an arbitrary EtherType with no authentication. Each such frame permanently consumes one buffer from the finite RX pool (CONFIG_NET_PKT_RX_COUNT), so a brief broadcast flood exhausts the pool and the device can no longer receive traffic until it is rebooted — a persistent denial of service. There is no confidentiality or integrity impact. The fix makes eth_bridge_handle_locally() propagate the real net_verdict and return NET_CONTINUE for locally-kept frames, writing the bridge interface back through a new dst_iface out-parameter so the packet follows the normal receive path and is unreferenced exactly once.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

