EUVD-2026-101340Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain adjacent-network or USB-gadget access to interface
-
DeliverySend 16-byte broadcast frame with ethertype 0x8100, TCI 0x0000
-
ExploitParser reinterprets short buffer as 18-byte VLAN header
-
Executionnet_buf length underflows, data pointer advances past storage
-
ImpactNode panic or out-of-bounds read disclosing/corrupting memory
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Bounds checking, read limits
MITRE ATT&CK
1 technique across 1 tactic: Collection The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the target to be built with CONFIG_NET_VLAN=y AND have a VLAN enabled on the receiving Ethernet interface AND use a MAC that does not strip VLAN tags in hardware (ETHERNET_HW_VLAN_TAG_STRIP not set); these three together are the gating preconditions and are non-default. Given those, no knowledge of the node's VLAN configuration is needed: a single unauthenticated 14-17 byte frame with ethertype 0x8100 and TCI 0x0000 sent to a broadcast destination suffices (priority tag 0 resolves to the base interface). Exploitation is limited to attackers with adjacent/link-local reach - or a malicious USB host via the CDC ECM/NCM gadget classes, which forward sub-60-byte host-supplied frames directly to net_recv_data(). Impact severity further depends on build flags: assertion-enabled builds panic (DoS only), while production builds with assertions and CONFIG_NET_BUF_HARDENING off suffer the length underflow enabling out-of-bounds reads with disclosure/corruption potential. |
| Impact | The CVSS vector (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H, 7.1) is internally consistent with the description: adjacent-network reach (AV:A), trivial crafting of a single 14-17 byte frame (AC:L), no authentication (PR:N), no user interaction (UI:N), and a reliable availability impact (A:H) via node panic or buffer-length underflow. The out-of-bounds read supports the C:L rating and the described information-disclosure/corruption potential. However, real-world risk is sharply constrained by configuration: only builds with CONFIG_NET_VLAN=y, a VLAN enabled on the receiving interface, and a MAC that does NOT offload VLAN tag stripping (ETHERNET_HW_VLAN_TAG_STRIP absent) are exploitable, so this is NOT a broad default-config issue despite the high-ish CVSS. No EPSS score was provided and the CVE is NOT in CISA KEV, so there is no evidence of active or widespread exploitation - treat the A:H as a plausible-but-conditional DoS rather than a mass-exploitation priority. There is no standalone weaponized exploit in the inputs, but the patch commit ships a precise reproducing ztest (test_vlan_truncated_header) that demonstrates the condition, lowering the barrier to building a trigger. Priority should be elevated for products shipping USB CDC ECM/NCM gadget networking with VLAN enabled, since those paths forward sub-60-byte host frames straight to the parser. |
| Exploit ScenarioDerived | An attacker on the same Ethernet link (or a malicious USB host attached to a Zephyr device exposing a CDC ECM/NCM gadget) sends a single 16-byte broadcast frame with ethertype 0x8100 and VLAN TCI 0x0000. Because net_eth_get_vlan_iface() accepts priority tag 0 and the broadcast destination passes the 'frame is for me' check, the frame reaches the pull where ethernet_recv() reads the 18-byte VLAN header out of a buffer that holds fewer bytes. On assertion-enabled builds the node panics; on production builds the uint16_t length underflows to 65534, advancing buf->data past the fragment and causing out-of-bounds reads with information-disclosure and memory-corruption potential. No public weaponized exploit is identified, but the vendor patch includes a reproducing test case. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 14, 2026
Malformed 802.1Q Ethernet frames can panic or corrupt the network receive path in Zephyr RTOS builds that have CONFIG_NET_VLAN=y and a VLAN enabled on the receiving Ethernet interface. ethernet_recv() checks only that the first buffer holds a 14-byte plain Ethernet header, then reinterprets that same buffer as an 18-byte VLAN header when the ethertype is 0x8100, reading the TCI and inner ethertype from offsets 14-17 beyond the buffer's length and raising hdr_len to 18 so net_buf_pull() removes more bytes than exist. A single unauthenticated 14-17 byte broadcast frame with ethertype 0x8100 and TCI 0x0000 suffices, reachable by an adjacent/link-local attacker or a malicious USB host through the CDC ECM/NCM gadget classes; assertion-enabled builds panic (denial of service), while production builds with assertions and CONFIG_NET_BUF_HARDENING disabled suffer a uint16_t length underflow to 65534 that leaves later parsers reading far outside the fragment, giving out-of-bounds access with information-disclosure and corruption potential. No public exploit identified at time of analysis; exploitation is gated by the non-default VLAN configuration and hardware VLAN tag stripping absent.
RemediationAI
Primary fix: update Zephyr to a revision containing upstream commit fd3c6fedf6b639977a80e52b680b15672c31f3ef, which adds a check that pkt->buffer->len is at least sizeof(struct net_eth_vlan_hdr) before the VLAN tag is read and before hdr_len is raised, dropping the frame otherwise so hdr_len is only ever 14 or 18 with both sizes validated against the buffer; per the referenced commit/PR this is an upstream fix and a released patched version number is not independently confirmed, so verify the commit is present in the tree you build from, and see advisory GHSA-79rf-rwff-f4vg. If upgrading is not immediately possible, the most effective compensating control is to build with CONFIG_NET_VLAN=n or remove VLANs from the receiving Ethernet interface, which eliminates the vulnerable code path entirely at the cost of losing VLAN segmentation on that port. Where VLANs are required, enable ETHERNET_HW_VLAN_TAG_STRIP so the MAC removes tags before the stack sees them, or ensure CONFIG_ASSERT and CONFIG_NET_BUF_HARDENING are enabled so the malformed frame causes a contained panic instead of a length underflow and out-of-bounds access, accepting that a remote denial of service remains reachable. Finally, restrict adjacent/link-local reach to the affected interface and do not expose USB CDC ECM/NCM gadget classes to untrusted hosts, since those drivers bypass the 60-byte Ethernet minimum and deliver the hostile short frame directly to the receive path.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Zephyr's Ethernet L2 receive handler in subsys/net/l2/ethernet/ethernet.c operates on net_buf fragments. Its preliminary validation assumes struct net_eth_hdr (14 bytes: 6-byte destination, 6-byte source, 2-byte ethertype). When the ethertype is 0x8100 and VLAN support is compiled in and enabled on the interface, the code casts the same buffer to struct net_eth_vlan_hdr (18 bytes) and reads the VLAN TCI at offsets 14-15 and the inner ethertype at 16-17 without re-validating pkt->buffer->len, a classic CWE-125 out-of-bounds read. It then sets hdr_len to 18 and calls net_buf_pull(), which removes more bytes than the fragment holds: with assertions on, net_buf_simple_pull() asserts and the node panics; with assertions off and CONFIG_NET_BUF_HARDENING off, the uint16_t length underflows to 65534 and buf->data advances past the fragment's storage, so subsequent protocol parsers read attacker-influenced out-of-bounds memory and any net_buf_add() computes tailroom from the bogus length. Reachability is eased because the receive path enforces no 60-byte Ethernet minimum, and the USB CDC ECM/CDC NCM gadget class drivers hand host-supplied frames of arbitrary non-zero length directly to net_recv_data(); no attacker knowledge of the target's VLAN configuration is needed, since net_eth_get_vlan_iface() maps priority tag 0 to the base interface and a broadcast destination satisfies the "for me" check.
Know when Zephyr gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H
Link-local or USB-adjacent single crafted frame (AV:A), no auth or interaction (PR:N/UI:N), trivial to craft (AC:L); reliable panic/underflow gives A:H and OOB read gives C:L, with corruption only potential so I:N.
Primary rating from Vendor (zephyr).
CVSS VectorVendor: zephyr
DescriptionCVE.org
ethernet_recv() in subsys/net/l2/ethernet/ethernet.c validates only that the first net_buf of a received frame holds a plain 14-byte struct net_eth_hdr. When the ethertype is 0x8100 and VLAN is enabled on the interface, the same buffer is reinterpreted as the 18-byte struct net_eth_vlan_hdr without re-checking the length: the VLAN TCI and the inner ethertype are read from offsets 14..17, past pkt->buffer->len, and hdr_len is raised to 18 so the subsequent net_buf_pull() 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: net_eth_get_vlan_iface() 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 net_recv_data().
With assertions enabled, net_buf_simple_pull() asserts and the node panics. In a production build (assertions and CONFIG_NET_BUF_HARDENING off) the uint16_t 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 net_buf_add() 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 CONFIG_NET_VLAN=y that have a VLAN enabled on the receiving Ethernet interface, and whose MAC does not strip VLAN tags in hardware (ETHERNET_HW_VLAN_TAG_STRIP), are affected. The fix rejects the frame before the tag is read, so hdr_len is thereafter either 14 or 18 with both sizes validated against pkt->buffer->len.
Executive ViewAI
Zephyr RTOS builds that enable VLAN processing and receive Ethernet traffic on an affected interface can be crashed or have memory corrupted by a single malformed 802.1Q frame, creating a denial-of-service and potential out-of-bounds access risk in connected products. Because the issue is reachable from adjacent/link-local networks or a malicious USB host using CDC ECM/NCM gadget classes, leadership should treat it as a high-priority availability and firmware-integrity issue for any product line using those configurations. Patch available per vendor advisory; no public exploit identified at time of analysis.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Potential off-by-one buffer overflow vulnerability in the Zephyr fuse file system. Rated critical severity (CVSS 10.0),
An out-of-bounds write in the Zephyr RTOS DNS resolver (dns_unpack_name()) lets a crafted DNS response corrupt memory on
Possible variant of CVE-2021-3434 in function le_ecred_reconf_req. Rated critical severity (CVSS 9.8), this vulnerabilit
Unchecked user input length in /subsys/net/l2/wifi/wifi_shell.c can cause buffer overflows. Rated critical severity (CVS
Potential buffer overflow vulnerability in the Zephyr CAN bus subsystem. Rated critical severity (CVSS 9.8), this vulner
Integer Underflow in 6LoWPAN IPHC Header Uncompression in Zephyr. Rated critical severity (CVSS 9.8), this vulnerability
Buffer overflow in Zephyr USB DFU DNLOAD. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable
DOS: Incorrect 802154 Frame Validation for Omitted Source / Dest Addresses. Rated critical severity (CVSS 9.8), this vul
zephyr-rtos version 1.12.0 contains a NULL base pointer reference vulnerability in sys_ring_buf_put(), sys_ring_buf_get(
Potential buffer overflow vulnerabilities n the Zephyr Bluetooth subsystem. Rated critical severity (CVSS 9.6), this vul
The documentation specifies that the BT_GATT_PERM_READ_LESC and BT_GATT_PERM_WRITE_LESC defines for a Bluetooth characte
Potential buffer overflows in the Bluetooth subsystem due to asserts being disabled in /subsys/bluetooth/host/hci_core.c
Exploit-DB