ZephyrProject Zephyr up to 4.4.1 Ethernet Bridge bridge_input.c eth_bridge_input_process denial of service

Summaryinfo

A vulnerability classified as critical has been found in ZephyrProject Zephyr up to 4.4.1. This impacts the function eth_bridge_input_process of the file subsys/net/l2/ethernet/bridge/bridge_input.c of the component Ethernet Bridge. This manipulation causes denial of service. This vulnerability is tracked as CVE-2026-14696. The attack is possible to be carried out remotely. No exploit exists.

Detailsinfo

A vulnerability has been found in ZephyrProject Zephyr up to 4.4.1 and classified as critical. Affected by this vulnerability is the function eth_bridge_input_process of the file subsys/net/l2/ethernet/bridge/bridge_input.c of the component Ethernet Bridge. The manipulation with an unknown input leads to a denial of service vulnerability. The CWE definition for the vulnerability is CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use. As an impact it is known to affect availability. The summary by CVE is:

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.

The advisory is shared at github.com. This vulnerability is known as CVE-2026-14696 since 07/04/2026. The exploitation appears to be easy. The attack can be launched remotely. The exploitation doesn't need any form of authentication. Technical details are known, but no exploit is available. MITRE ATT&CK project uses the attack technique T1499 for this issue.

Upgrading to version 4.4.2 eliminates this vulnerability. Applying the patch 4eb007af465a1d28f2f35d93ecf139cc62c542a7 is able to eliminate this problem.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Type

• Project Management Software

Vendor

• ZephyrProject

Name

• Zephyr

Version

• 4.4.0
• 4.4.1

CPE 2.3info

• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion