SecvalisbySYSDEVOPS.EU
Katalog CVE
EnglishPolski

CVE-2026-16515

ŚrednieCVSS 4.7
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.20%

Percentyl 10 - wyżej niż 10% wszystkich znanych CVE

Streszczenie

Funkcja net_icmpv6_send_error() w stosie sieciowym Zephyr implementowała tylko jedną z trzech reguł tłumienia z RFC 4443 sekcja 2.4, przez co nie sprawdzała, czy źródło pakietu wskazuje pojedynczy węzeł ani czy pakiet był wysłany na adres multicast. Nieuwierzytelniony atakujący w tej samej sieci może wysłać jeden pakiet IPv6 na adres ff02::1 ze sfałszowanym źródłem ofiary, powodując, że wszystkie węzły Zephyr wyślą komunikaty ICMPv6 Parameter Problem do ofiary (refleksja z amplifikacją), albo wysłać pakiet unicast z adresem źródłowym multicast, co zamienia go w zalewający łącze ramkę multicast.

Ocena ryzyka

Atak prowadzi do obniżenia dostępności współdzielonego łącza i ofiary refleksji, a atakujący może ukryć własny adres za odpowiadającymi węzłami. Skutek jest silniejszy w sieciach mesh o ograniczonych zasobach, takich jak 802.15.4/Thread, gdzie multicast link-local jest zalewany skok po skoku.

Rekomendacja

Zaktualizować Zephyr do wersji zawierającej poprawkę dodającą oba sprawdzenia tłumienia w net_icmpv6_send_error() przed alokacją pakietu odpowiedzi, z zachowaniem wyjątków dla NET_ICMPV6_PACKET_TOO_BIG i Parameter Problem Code 2. Należy pamiętać, że odpowiednik IPv4 net_icmpv4_send_error() nadal ma lukę dla adresów multicast i nieunikalnych źródeł.

Inne podatności w Zephyr

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

net_icmpv6_send_error() in subsys/net/ip/icmpv6.c implemented only one of the three RFC 4443 section 2.4 suppression rules (do not answer an ICMPv6 error with an ICMPv6 error). It did not check whether the triggering packet's source address identifies a single node (rule e.6) or whether the packet was sent to a multicast destination (rule e.3, whose only exceptions are Packet Too Big and Parameter Problem Code 2). Of the five call sites, only the port-unreachable path in subsys/net/ip/connection.c carried an equivalent guard of its own; the extension-header, unknown-next-header and fragmentation paths in subsys/net/ip/ipv6.c and subsys/net/ip/ipv6_fragment.c had none. An unauthenticated attacker with access to the same link can exploit this in two ways. Sending a single IPv6 packet to the link-local all-nodes group ff02::1 carrying an unrecognized next-header value, with the source address spoofed to a chosen victim, causes every Zephyr node on the link to emit an ICMPv6 Parameter Problem message to that victim — a reflector with an amplification factor equal to the number of nodes. Alternatively, sending a unicast packet whose source address is a multicast address causes the node to transmit its ICMPv6 error to that multicast address, turning one unicast packet into a link-flooded multicast frame. Packets addressed to ff02::1 are accepted unconditionally by ipv6_input(), and no check rejects a multicast source address, so no special configuration is required. The impact is degraded availability of the shared link and of the reflection victim, together with the ability for the attacker to hide its own address behind the responding nodes. The effect is amplified on constrained mesh links such as 802.15.4/Thread, where link-local multicast is flooded hop by hop. There is no memory-safety consequence: the error packet itself is well formed, it is simply emitted in cases where the protocol forbids it. The fix adds both suppression checks at the single choke point in net_icmpv6_send_error(), before any reply packet is allocated, preserving the RFC-mandated exceptions for NET_ICMPV6_PACKET_TOO_BIG and Parameter Problem Code 2. Note that the IPv4 counterpart net_icmpv4_send_error() in subsys/net/ip/icmpv4.c still checks only for a broadcast destination and retains an equivalent gap for multicast destinations and non-unique sources.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS