CVE-2026-14696: Ethernet bridge RX packet leak enables denial of service via RX buffer-pool exhaustion

When Ethernet bridging is enabled (CONFIGNETETHERNETBRIDGE), ethbridgeinputprocess() in subsys/net/l2/ethernet/bridge/bridgeinput.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 ethbridgehandlelocally() and returned NETOK. That helper does not consume the packet — it only calls bridgeifacerecv() (via virtualrecv()), which returns NETCONTINUE without taking ownership of pkt.

The NETOK verdict then propagates through ethernetrecv() up to processingdata() in subsys/net/ip/netcore.c, where NETOK is interpreted as "the packet was consumed, do not free it." Because no consumer actually took ownership, the RX netpkt is never returned to the pool and is leaked. The concretely reproducible leak occurs for frames whose EtherType has no registered L3 handler when CONFIGNETETHERNETFORWARDUNRECOGNISEDETHERTYPE is set (default y when CONFIGNETSOCKETSPACKET is enabled): the fall-through L3 dispatch does not overwrite the NETOK verdict, so ethernetrecv() returns NETOK 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 (CONFIGNETPKTRXCOUNT), 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 ethbridgehandlelocally() propagate the real netverdict and return NETCONTINUE for locally-kept frames, writing the bridge interface back through a new dstiface out-parameter so the packet follows the normal receive path and is unreferenced exactly once.