CVE-2026-14696

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.

• CWE-401

• https://github.com/zephyrproject-rtos/zephyr/commit/4eb007af465a1d28f2f35d93ecf139cc62c542a7
• https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-3m4w-wc4v-766q

Published

Aug 31, 2026

Last Modified

Sep 1, 2026

Status

Awaiting Analysis

• How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
• Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
• PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
• AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.

• CVE-2026-14690A weakness has been identified in SourceCodester Multi-Vendo…7.3
• CVE-2026-14691A security vulnerability has been detected in SourceCodester…6.3
• CVE-2026-14692A vulnerability was detected in SourceCodester Multi-Vendor …6.3
• CVE-2026-14693A flaw has been found in SourceCodester Multi-Vendor Online …5.4
• CVE-2026-14694A vulnerability has been found in SourceCodester Multi-Vendo…6.3
• CVE-2026-14695A vulnerability was found in SourceCodester Multi-Vendor Onl…7.3
• CVE-2026-14697net_ipv6_send_ns() in subsys/net/ip/ipv6_nbr.c allocates a t…6.5
• CVE-2026-14698A security flaw has been discovered in SourceCodester Syllab…6.3
• CVE-2026-14699A weakness has been identified in zcaceres markdownify-mcp u…4.8
• CVE-2026-1470n8n contains a critical Remote Code Execution (RCE) vulnerab…9.9
• CVE-2026-14700A security vulnerability has been detected in code-projects …7.3
• CVE-2026-14701A vulnerability was detected in code-projects Internship Man…6.3