CVE-2026-19673: Out-of-bounds read and net_buf length underflow in Zephyr Ethernet L2 when parsing a truncated VLAN header
ethernetrecv() in subsys/net/l2/ethernet/ethernet.c validates only that the first netbuf of a received frame holds a plain 14-byte struct netethhdr. When the ethertype is 0x8100 and VLAN is enabled on the interface, the same buffer is reinterpreted as the 18-byte struct netethvlanhdr without re-checking the length: the VLAN TCI and the inner ethertype are read from offsets 14..17, past pkt->buffer->len, and hdrlen is raised to 18 so the subsequent netbufpull() removes more bytes than the buffer holds.
A single unauthenticated frame of 14 to 17 bytes carrying the VLAN ethertype triggers this. No knowledge of the node's VLAN configuration is needed: netethgetvlaniface() returns the base interface for the priority tag 0, and a broadcast destination address satisfies the "frame is for me" test, so a 16-byte broadcast frame with ethertype 0x8100 and TCI 0x0000 reaches the pull. Nothing in the receive path enforces the 60-byte Ethernet minimum — the USB CDC ECM and CDC NCM gadget classes in particular hand host-supplied frames of any non-zero length straight to netrecvdata().
With assertions enabled, netbufsimplepull() asserts and the node panics. In a production build (assertions and CONFIGNETBUFHARDENING off) the uint16t buffer length underflows to 65534 and buf->data is advanced past the end of the fragment's storage, so every later parser reads far outside the buffer and any netbufadd() on that fragment computes tailroom from the underflowed length. The result is a reliable remote denial of service and out-of-bounds access with information-disclosure and corruption potential.
Only configurations built with CONFIGNETVLAN=y that have a VLAN enabled on the receiving Ethernet interface, and whose MAC does not strip VLAN tags in hardware (ETHERNETHWVLANTAGSTRIP), are affected. The fix rejects the frame before the tag is read, so hdrlen is thereafter either 14 or 18 with both sizes validated against pkt->buffer->len.
Affected Software
Event History
Frequently Asked Questions
Which deployments are most exposed?
Interfaces with VLAN enabled are affected by the vulnerable receive path. USB CDC ECM and CDC NCM gadget configurations are specifically exposed because they pass host-supplied non-zero-length frames directly to net_recv_data() without enforcing the Ethernet 60-byte minimum.
What does an attacker need to send?
An unauthenticated attacker only needs to deliver a 14- to 17-byte Ethernet frame with ethertype 0x8100. A 16-byte frame addressed to broadcast with VLAN TCI 0x0000 can reach the vulnerable pull operation; the attacker does not need to know the node's VLAN configuration.
What is the observable effect with assertions enabled?
net_buf_simple_pull() asserts when the receive path attempts to remove the 18-byte VLAN header from a shorter buffer. This causes the node to panic.
How can I assess whether a device is exposed?
Check whether the device has VLAN enabled on an Ethernet interface and whether it accepts externally supplied frames shorter than the Ethernet minimum. USB CDC ECM and CDC NCM gadget interfaces are specifically identified as accepting such frames.