Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-31T19:16:46.140Z",
  "pubdate": "2026-08-31T19:16:46.140Z",
  "executiveSummary": "A memory leak vulnerability exists in the Ethernet bridging subsystem of Zephyr OS when configured with CONFIG_NET_ETHERNET_BRIDGE. The issue stems from improper handling of the net_verdict during packet reception, leading to the permanent exhaustion of the RX packet buffer pool.\nThis vulnerability is classified as a resource management error (CWE-401: Improper Release of Memory Before Removing Last Reference). An unauthenticated attacker positioned on the local L2 segment can trigger this condition by injecting specifically crafted broadcast or multicast frames with unrecognized EtherTypes.\nThe impact is a persistent Denial of Service (DoS). Once the finite buffer pool (defined by CONFIG_NET_PKT_RX_COUNT) is exhausted, the device loses the ability to process any further incoming network traffic, requiring a hard reboot to restore functionality. No impact on data confidentiality or integrity has been identified, as the flaw is strictly confined to memory allocation tracking within the networking stack.",
  "technicalDetails": "The root cause of this vulnerability lies in the logic within eth_bridge_input_process() located in subsys/net/l2/ethernet/bridge/bridge_input.c. When a frame is received that requires delivery to the local network stack, the bridge logic invokes eth_bridge_handle_locally(). This function subsequently triggers bridge_iface_recv() via virtual_recv(), which returns a NET_CONTINUE verdict, signifying that the packet has not been consumed by the bridging logic.\nHowever, eth_bridge_input_process() returns NET_OK to the higher-level ethernet_recv() function. In the Zephyr network stack, the return value NET_OK is interpreted by the stack's packet management logic as an indication that the packet has been successfully consumed and that the ownership of the net_pkt buffer has been transferred. Because the packet was never actually consumed by any L3 handler, the buffer reference count is never decremented, causing the packet to remain permanently allocated in the RX pool.\nThe exploitation process is straightforward and does not require elevated privileges or authentication. An attacker on the bridged L2 segment generates a flood of broadcast or multicast Ethernet frames featuring an arbitrary or unrecognized EtherType. This is particularly effective when CONFIG_NET_ETHERNET_FORWARD_UNRECOGNISED_ETHERTYPE is enabled. In this state, the L3 dispatch logic fails to re-evaluate the NET_OK status provided by the bridge handler, ensuring that the verdict propagates to the processing_data() function in subsys/net/ip/net_core.c without modification.\nBecause the buffer is never released, each malicious packet effectively removes one unit of capacity from the static CONFIG_NET_PKT_RX_COUNT pool. As this pool is finite, a high-volume transmission of these packets will rapidly deplete the available memory, leading to an immediate and permanent exhaustion state. This effectively silences the device from all network communication. Remediation requires an architectural change to ensure that eth_bridge_handle_locally() correctly propagates the verdict and utilizes an out-parameter for the destination interface, forcing the stack to maintain a proper reference count and ensure the packet is disposed of once processing is completed."
}