Skip to content
statance
MenuClose
medium · CVSS 6.5

CVE-2026-82962

Out-of-bounds write in Zephyr Ethernet L2 when adding the link-layer header to a forwarded packet

Published 28 Oct 2026 · Source updated 5 Nov 2026 · Retrieved 2026-11-05 18:01 UTC

Statance checks for CVE-2026-82962. Connected servers are checked automatically against the fixed versions their distribution or package ecosystem has published for it, including app dependency lockfiles. Check my servers ↗
Monitor this CVE ↗Full CVE monitoring on Pro and Business

What happened?

ethernet_fill_header() in subsys/net/l2/ethernet/ethernet.c can prepend the Ethernet header in place, by pushing it into the headroom of the packet's first fragment, instead of allocating a separate header fragment. Before this fix the in-place path was selected purely from the build-time value of CONFIG_NET_L2_ETHERNET_RESERVE_HEADER, with no check that the packet actually has that headroom, and then called net_buf_push(pkt->buffer, hdr_len). Only Ethernet TX allocations reserve that space: net_pkt_alloc_buffer() invokes the L2 alloc hook (ethernet_l2_alloc()) only when is_pkt_tx() is true and the packet's interface is the Ethernet interface.

A packet that was allocated by a different L2 and then handed to Ethernet for transmission therefore has too little (usually zero) headroom. Such packets are produced by ordinary routing and tunnelling paths: net_route_packet_if() re-targets a received packet to another interface when CONFIG_NET_IPV4_FORWARDING / CONFIG_NET_IPV6_FORWARDING are enabled (for example an 802.15.4/OpenThread or PPP interface forwarding to Wi-Fi/Ethernet), net_route_ipv6_mcast_forward_packet() forwards an RX-slab clone that carries no reserve, and the IPIP tunnel interface_send() prepends an outer IP header allocated on the virtual interface. In these configurations a remote or adjacent attacker triggers the condition simply by sending traffic that the device forwards.

Because net_buf_simple_push() only asserts on the headroom bound, a build without CONFIG_ASSERT (and without the newer CONFIG_NET_BUF_HARDENING) moves the fragment data pointer below the start of its data block and writes 14 bytes — 18 with VLAN — of Ethernet header out of bounds. With the default fixed-size buffer pools this overwrites the tail of the neighbouring buffer's payload or memory preceding the pool array; with variable-size pools it overwrites the buffer reference count and the heap chunk header. The attacker controls neither the written bytes nor the offset, so the practical impact is memory corruption leading to a crash, packet corruption, or heap inconsistency rather than controlled code execution. The fix takes the in-place path only when net_buf_headroom(pkt->buffer) is large enough and otherwise falls back to a separate header fragment.

Description supplied by CVE Program. Formatting is simplified; follow the original advisory for full details.

Affected software and versions

Source-provided software and version information
SoftwareVersion informationFixed version
zephyrzephyrprojectaffected: 4.1.0 to < 4.3.2; affected: 4.4.0 to < 4.5.0See vendor advisory

Version information comes from the source record and can include unaffected products and exceptions. Distribution packages may contain backported fixes: an older upstream version alone does not prove a server is affected.

Is it being exploited?

This CVE was not listed in the CISA catalogue at our last retrieval. This does not establish that exploitation is absent.

CISA data retrieved 2026-11-06 16:38 UTC. Check CISA ↗

How to respond

  1. Confirm the product, installed package version, and any configuration requirements in the vendor advisory.
  2. Follow the vendor’s remediation or workaround guidance in the references below. Structured fixed-version data is unavailable here; the publisher’s description may include a fix or workaround.
  3. Restart affected services if required, then verify the running version. Known exploitation may warrant investigation as well as patching.

Sources and remediation references

This public advisory does not determine whether a particular server is affected. Records are refreshed as sources change; verify urgent decisions against the original advisory.

← Browse the public CVE feed