CVE-2026-82962 in Zephyr
Zusammenfassung
von VulDB • 29.10.2026
ethernet_fill_header() in subsys/net/l2/ethernet/ethernet.c kann den Ethernet-Header an Ort und Stelle voranstellen, indem er ihn in den Headroom des ersten Fragments des Pakets schiebt, anstatt ein separates Header-Fragment zu allozieren. Vor dieser Korrektur wurde der Pfad für die Bearbeitung an Ort und Stelle ausschließlich auf Basis des Build-Zeit-Werts von CONFIG_NET_L2_ETHERNET_RESERVE_HEADER ausgewählt, ohne eine Prüfung, ob das Paket tatsächlich über diesen Headroom verfügt, und rief dann net_buf_push(pkt->buffer, hdr_len) auf. Nur Ethernet-TX-Allokationen reservieren diesen Speicherplatz: net_pkt_alloc_buffer() ruft den L2-Allozierungshook (ethernet_l2_alloc()) nur dann auf, wenn is_pkt_tx() true ist und die Schnittstelle des Pakets die Ethernet-Schnittstelle ist.
Ein Paket, das von einer anderen L2-Ebene alloziert wurde und anschließend zur Übertragung an Ethernet übergeben wird, verfügt daher über zu wenig (in der Regel null) Headroom. Solche Pakete werden durch normale Routing- und Tunneling-Pfade erzeugt: net_route_packet_if() zielt ein empfangenes Paket auf eine andere Schnittstelle um, wenn CONFIG_NET_IPV4_FORWARDING / CONFIG_NET_IPV6_FORWARDING aktiviert sind (z. B. Weiterleitung von einer 802.15.4/OpenThread- oder PPP-Schnittstelle zu Wi-Fi/Ethernet), net_route_ipv6_mcast_forward_packet() leitet einen RX-slab-Klon weiter, der keine Reservierung enthält, und die IPIP-Tunnel-Schnittstellenfunktion interface_send() stellt einen äußeren IP-Header voran, der auf der virtuellen Schnittstelle alloziert wurde. In diesen Konfigurationen löst ein entfernter oder benachbarter Angreifer diese Bedingung einfach aus, indem er Datenverkehr sendet, den das Gerät weiterleitet.
Da net_buf_simple_push() nur eine Assertion an der Headroom-Grenze durchführt, führt ein Build ohne CONFIG_ASSERT (und ohne das neuere CONFIG_NET_BUF_HARDENING) dazu, dass der Zeiger auf die Fragmentdaten unter den Start seines Datenblocks verschoben wird und 14 Bytes – mit VLAN sind es 18 Byte – des Ethernet-Headers außerhalb der Grenzen geschrieben werden. Bei standardmäßigen Pools fester Größe überschreibt dies das Ende der Nutzlast oder den Speicher vor dem Pool-Array des benachbarten Puffers; bei Pools variabler Größe überschreibt es die Referenzzählung des Puffers und den Heap-Chunk-Header. Der Angreifer hat weder Kontrolle über die geschriebenen Bytes noch über den Offset, sodass die praktische Auswirkung auf Speicherkorruption führt, die einen Absturz, eine Paketkorruption oder Heap-Inkonsistenz zur Folge hat, anstatt einer kontrollierten Code-Ausführung. Die Korrektur wählt nur dann den Pfad für die Bearbeitung an Ort und Stelle aus, wenn net_buf_headroom(pkt->buffer) groß genug ist, und fällt andernfalls auf ein separates Header-Fragment zurück.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.