CVE-2026-14696
Received Received - Intake

Memory Leak in Zephyr RTOS Ethernet Bridge

Publication date: 2026-08-31

Last updated on: 2026-08-31

Assigner: Zephyr Project

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-08-31
Last Modified
2026-08-31
Generated
2026-08-31
AI Q&A
2026-08-31
EPSS Evaluated
N/A
NVD
CVE-2026-14696
EUVD
EUVD-2026-68728

Affected Vendors & Products

Showing 4 associated CPEs
Vendor Product Version / Range
zephyrproject zephyr 4.4.0
zephyrproject zephyr 4.4.1
zephyrproject zephyr From 4.4.2 (inc)
zephyrproject zephyr to 2026-14696 (inc)

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-401 The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability is a memory leak in the Zephyr RTOS network stack when Ethernet bridging is enabled. When a packet needs local processing, the function eth_bridge_input_process incorrectly returns NET_OK, signaling the packet was consumed when it was not. This causes RX packets to leak and never return to the buffer pool, eventually exhausting it.

Detection Guidance

Detecting this vulnerability requires monitoring for packet leaks in the RX buffer pool of Zephyr RTOS devices with Ethernet bridging enabled. Check for increasing packet buffer usage or exhaustion in CONFIG_NET_PKT_RX_COUNT. Commands may include monitoring net_pkt pool usage via system logs or debugging tools in Zephyr RTOS.

Impact Analysis

An attacker on the same local network segment can send broadcast or multicast frames with unrecognized EtherTypes to trigger the leak. This exhausts the RX buffer pool, causing the device to stop receiving traffic until rebooted. The impact is a persistent denial of service with no confidentiality or integrity loss.

Compliance Impact

This vulnerability primarily causes a denial of service by exhausting the RX buffer pool, leading to device unavailability. It does not directly impact confidentiality or integrity of data, which are key concerns for GDPR and HIPAA. However, prolonged unavailability could indirectly affect compliance by disrupting systems handling sensitive data.

Mitigation Strategies

Upgrade Zephyr RTOS to version 4.4.2 or later to apply the fix. Disable Ethernet bridging if not required. Monitor network traffic for unusual broadcast/multicast frames with unrecognized EtherTypes. Restrict access to the L2 segment to trusted devices only.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-14696. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart