CVE-2026-10686 in Zephyr
Zusammenfassung
von VulDB • 01.08.2026
Der IPv6-Weiterleitungspfad von Zephyr hat geroutete Unicast-Pakete erneut gesendet, ohne die IPv6-Hop-Limit-Beschränkung jemals zu dekrementieren. Beide Routing-Zweige von ipv6_route_packet() (subsys/net/ip) waren betroffen: der explizite-Routing-Pfad (net_route_packet()) und der on-Link-Cross-Interface-Pfad (net_route_packet_if()). Jeder dieser Pfade setzte das Paketweiterleitungsflag und rief net_send_data() auf, wobei die Hop-Limit-Beschränkung unberührt blieb und keine Ablaufprüfung erfolgte.
Gemäß RFC 8200 ist die Dekrementierung der Hop-Limit-Beschränkung der Mechanismus, der die Lebensdauer von Paketen begrenzt und Routing-Schleifen beendet; ohne diesen Mechanismus leitet ein Gerät, das als IPv6-Router fungiert, Schleifpakete unbegrenzt weiter. Ein Angreifer im Übertragungsweg (on-path), der eine vorübergehende L3-Schleife auslösen oder ausnutzen kann, verwandelt diese in einen permanenten Weiterleitungssturm, was zu einer Erschöpfung von CPU-/Bandbreiten-Ressourcen (Verfügbarkeits-DoS) auf dem Forwarder und benachbarten Links führt; auch Pfadfindung und Loop-Diagnosen, die sich auf den Ablauf der Hop-Limit-Beschränkung stützen, werden dadurch wirkungslos.
Betroffene Konfigurationen: In jeder betroffenen Version wird der Weiterleitungspfad über CONFIG_NET_ROUTE erreicht (standardmäßig aktiviert, wenn CONFIG_NET_IPV6_NBR_CACHE festgelegt ist), zusammen mit CONFIG_NET_ROUTING für das Cross-Interface-Routing. Beachten Sie, dass CONFIG_NET_IPV6_FORWARDING und CONFIG_NET_IPV4_FORWARDING – die in der Korrektur und in den Beweisnotizen dieser Advisory erscheinen – erst nach v4.4.0 eingeführt wurden, als die Routing-Optionen aufgeteilt und umbenannt wurden; sie existieren in keiner betroffenen Version. Bei der Prüfung einer Konfiguration mit v4.4.1 oder früher sind CONFIG_NET_ROUTE und CONFIG_NET_ROUTING zu beachten.
IPv4 ist in keiner Version betroffen. Der IPv4-Weiterleitungspfad (net_route_ipv4_packet() in route_ipv4.c) wurde nach v4.4.0 hinzugefügt und war noch nie Teil einer veröffentlichten Version. Seine TTL-Dekrementierung und die Neuberechnung der IPv4-Header-Prüfsumme wurden als Teil derselben Korrektur in den Hauptzweig (main) übernommen, sodass die Beweisnotizen unten dies diskutieren, aber keine veröffentlichte Version ist über IPv4 erreichbar.
Betroffene Versionen sind v1.8.0 bis v4.4.1: v1.8.0 führte net_route_packet() ein und v2.2.0 fügte net_route_packet_if() hinzu; weder dekrementierte die Hop-Limit-Beschränkung. v4.3.1 enthält die Korrektur für den expliziten Routing-Pfad, aber nicht für den on-Link-Pfad, daher ist auch diese Version betroffen. Korrigiert im Hauptzweig durch 7d8f1afa7345 (expliziter-Routing-Pfad) und 589eadc74efa (on-Link-Pfad).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.