CVE-2026-14696 in Zephyr
Summary
by MITRE • 08/31/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/31/2026
This vulnerability represents a critical resource exhaustion flaw within the Zephyr RTOS networking stack, specifically affecting systems that utilize Ethernet bridging functionality enabled via CONFIG_NET_ETHERNET_BRIDGE. The root cause lies in an incorrect handling of packet ownership and verdict propagation during the processing of frames destined for local delivery on bridge member interfaces. When eth_bridge_input_process() determines that a received frame must also be delivered to the local network stack, it invokes eth_bridge_handle_locally(). This helper function calls into bridge_iface_recv via virtual_recv(), which returns NET_CONTINUE without assuming ownership of the packet buffer. However, eth_bridge_handle_locally incorrectly propagates this result as NET_OK back to its caller, ethernet_recv(). In the Zephyr networking architecture, a verdict of NET_OK explicitly signals that the consumer has successfully processed and consumed the packet, thereby instructing the upper layers not to free or return it to the memory pool. Consequently, because no actual component takes ownership of the net_pkt structure, the buffer is never returned to the RX pool defined by CONFIG_NET_PKT_RX_COUNT, resulting in a persistent memory leak for every such frame.
The operational impact of this flaw manifests as a severe denial of service condition due to resource exhaustion. The vulnerability is particularly exploitable when CONFIG_NET_ETHERNET_FORWARD_UNRECOGNISED_ETHERTYPE is enabled, which is the default configuration when packet sockets are active via CONFIG_NET_SOCKETS_PACKET. Under these conditions, any Ethernet frame with an EtherType that lacks a registered Layer 3 handler falls through to this specific code path without overwriting the NET_OK verdict. Since broadcast and multicast frames often carry arbitrary or unrecognized EtherTypes, an attacker on the same bridged L2 segment can trigger this leak by simply flooding the network with such frames. Because each leaked frame permanently consumes one entry from the finite RX packet pool, a relatively brief flood of maliciously crafted packets will exhaust all available buffers. Once the pool is depleted, the device loses its ability to receive any new traffic, effectively rendering it non-functional until a reboot clears the memory state. This constitutes a persistent denial of service that does not require authentication or complex exploitation techniques, relying solely on the volume of broadcast traffic with unrecognized types.
From a security classification perspective, this issue aligns with CWE-401, which describes missing release of memory after effective usage, and specifically relates to improper resource cleanup leading to resource exhaustion. In terms of attack vectors, it falls under MITRE ATT&CK techniques related to Denial of Service, particularly those involving network flooding or application-layer attacks that target resource limits rather than logic flaws. The lack of confidentiality or integrity impact means the primary risk is availability disruption for devices relying on Zephyr’s networking stack in bridged environments.
To mitigate this vulnerability, developers must ensure that packet ownership semantics are strictly adhered to throughout the receive path. As indicated by the fix description, eth_bridge_handle_locally should propagate the actual net_verdict rather than defaulting to NET_OK when no consumer takes ownership. Specifically, for locally kept frames where no L3 handler consumes the packet, the function should return NET_CONTINUE and utilize an out-parameter such as dst_iface to pass control back through the normal receive path. This ensures that ethernet_recv correctly interprets the state of the packet and returns it to the pool via net_pkt_unref or equivalent mechanisms exactly once per reception cycle. System administrators and developers using affected versions must apply this patch immediately, especially in environments where untrusted devices may be connected to bridged network segments. Until patched, limiting broadcast traffic or disabling CONFIG_NET_SOCKETS_PACKET if not required can reduce the attack surface, though these are only temporary workarounds for a fundamental code logic error.