Skip to content
Heist/ feed
Back to feed
Medium

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

Type: advisorySources: Official CVE List

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_AS

Products
zephyr
Affected versions
Not specified
Fixed versions
Not specified
CVEs
CVE-2026-82962
Confirmed fixed CVEs
Not specified
Updated in this feed
1 Nov 2026, 18:33 UTC · Revision 1

Source evidence

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

core-cve · Original source

Published 28 Oct 2026, 16:59 UTC

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_AS

cve:CVE-2026-82962

zephyr

Fixed versions: Not specified

Complete source record
{
  "id": "d43d678ad109d6c5a01970324441960b7686bed45a3cd94dbef90e3d78e46519",
  "url": "https://www.cve.org/CVERecord?id=CVE-2026-82962",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "Out-of-bounds write in Zephyr Ethernet L2 when adding the link-layer header to a forwarded packet",
    "summary": "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_AS",
    "evidence": "cve:CVE-2026-82962",
    "products": [
      {
        "name": {
          "value": "zephyr",
          "evidence": "/containers/cna/affected/0/product"
        },
        "prerequisites": [],
        "fixed_versions": [],
        "affected_versions": []
      }
    ],
    "severity": "medium",
    "structured": {
      "id": "CVE-2026-82962",
      "aliases": [
        "CVE-2026-82962"
      ],
      "metrics": [
        {
          "format": "CVSS",
          "cvssV3_1": {
            "version": "3.1",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H"
          }
        }
      ],
      "affected": [
        {
          "vendor": "zephyrproject",
          "product": "zephyr",
          "versions": [
            {
              "status": "affected",
              "version": "4.1.0",
              "versionType": "semver",
              "lessThanOrEqual": "4.4.2"
            }
          ],
          "packageName": "zephyr",
          "programFiles": [
            "subsys/net/l2/ethernet/ethernet.c"
          ],
          "collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
          "defaultStatus": "unaffected",
          "programRoutines": [
            {
              "name": "ethernet_fill_header"
            }
          ]
        }
      ],
      "modified": "2026-10-28T16:59:00.030Z",
      "provider": "cve",
      "references": [
        "https://github.com/zephyrproject-rtos/zephyr/commit/b39f86ea61d0a0fdd7e9f145110649394e2c22ca",
        "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-56gp-jq94-c9hh"
      ],
      "provider_metadata": {
        "cna": {
          "orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
          "shortName": "zephyr",
          "dateUpdated": "2026-10-28T16:59:00.030Z"
        }
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-82962",
        "evidence": "/cveMetadata/cveId"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/containers/cna/metrics"
  },
  "source_id": "core-cve",
  "document_id": 462556,
  "published_at": "2026-10-28T16:59:00.03+00:00"
}