Description

net_ipv6_send_ns() in subsys/net/ip/ipv6_nbr.c allocates a transmit net_pkt for a Neighbor Solicitation. When it is called with a data packet pending on an unresolved neighbor and that neighbor's pending_queue is already non-empty (an NS is already outstanding), the function appends the data packet and returns early without ever sending the NS via net_send_data() or releasing it with net_pkt_unref(). The freshly allocated NS net_pkt and its attached TX buffers are held only by a local variable and are leaked permanently, never returning to CONFIG_NET_PKT_TX_COUNT / CONFIG_NET_BUF_TX_COUNT. The leaking branch sits on the normal IPv6 transmit path: net_ipv6_prepare_for_send() (called from net_if.c) invokes net_ipv6_send_ns() for any outbound or forwarded IPv6 packet whose next hop is not yet in the neighbor cache. An on-link (adjacent) attacker can drive it deterministically by sending a burst of request packets (for example ICMPv6 echo requests or UDP datagrams) that all spoof a single non-existent on-link source address: the node generates a reply to each, the first reply queues an NS, and every subsequent reply during the roughly three-second INCOMPLETE resolution window takes the leaking branch and loses one TX packet. Router-configured nodes forwarding attacker traffic toward a non-existent on-link host leak identically. Because the leaked packets are never reclaimed and CONFIG_NET_PKT_TX_COUNT defaults to only 4 (14 for Ethernet), a brief low-rate burst exhausts the TX pool. Once exhausted the node can no longer allocate any transmit packet and cannot send TCP/UDP, ARP/ND, or any reply at all, producing a complete and persistent network denial of service that does not self-heal until reboot. The fix releases the unsent NS packet with net_pkt_unref(pkt) before the early return.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-31T20:17:03.253Z",
  "pubdate": "2026-08-31T20:17:03.253Z",
  "executiveSummary": "This vulnerability is a memory leak affecting the Zephyr OS IPv6 network stack, specifically within the Neighbor Discovery (ND) implementation.\nThe issue is classified as a resource exhaustion vulnerability that facilitates a permanent Denial of Service (DoS) attack.\nThe flaw originates in net_ipv6_send_ns() within subsys/net/ip/ipv6_nbr.c, where memory buffers allocated for transmit packets are improperly handled when a Neighbor Solicitation (NS) is already pending for a specific destination.\nAn on-link attacker can exploit this by flooding the target with traffic directed at non-existent link-local addresses, forcing the allocation of network packets that are never reclaimed.\nGiven that the default configuration for transmit packet pools (CONFIG_NET_PKT_TX_COUNT) is significantly low, an attacker can rapidly exhaust the entire pool of available transmit buffers.\nOnce exhausted, the affected node loses the ability to transmit any network traffic, including ICMPv6, TCP, and UDP packets, leading to a persistent state of network unavailability that remains until the device is power-cycled or rebooted.\nThe vulnerability is remotely exploitable without authentication by any attacker capable of sending traffic to the target node.",
  "technicalDetails": "The root cause of this vulnerability lies in an improper state management logic within the net_ipv6_send_ns() function in subsys/net/ip/ipv6_nbr.c. When the network stack attempts to transmit an IPv6 packet to a neighbor whose address resolution is incomplete (i.e., the neighbor cache entry is in the INCOMPLETE state), the system allocates a transmit net_pkt structure to encapsulate a Neighbor Solicitation message.\nIf a pending_queue already exists for the target neighbor—indicating that an NS has already been issued and the stack is awaiting a Neighbor Advertisement—the logic incorrectly assumes that the new NS allocation is redundant and performs an early exit. However, this early return fails to invoke net_pkt_unref() on the newly allocated net_pkt. Consequently, the memory associated with the net_pkt and its underlying TX buffers remains leaked, as there is no further reference to these objects to facilitate future garbage collection or resource reclamation.\nThe exploit flow is highly deterministic. An attacker targets an adjacent node by sending a sustained burst of packets (e.g., ICMPv6 Echo Requests or UDP datagrams) destined for a non-existent on-link IPv6 address. This forces the target node’s net_if.c module to invoke net_ipv6_prepare_for_send(), which subsequently triggers net_ipv6_send_ns().\nFor the first packet in the burst, the stack allocates an NS and initializes the resolution process. For all subsequent packets arriving while the initial NS is still pending (typically a three-second window), the function executes the leaky return branch. Each discarded packet results in the permanent loss of one entry from the finite TX pool defined by CONFIG_NET_PKT_TX_COUNT and CONFIG_NET_BUF_TX_COUNT.\nBecause the default TX pool size is typically small (e.g., 4 to 14), a low-rate burst of spoofed packets can exhaust the pool in milliseconds. Once the pool is empty, the Zephyr network stack becomes unable to allocate memory for any outbound transmission. This results in a comprehensive DoS state where the device cannot send responses to any network requests, rendering the network interface completely non-functional. Because this involves the exhaustion of static compile-time memory structures, the system cannot recover without a hard restart, making it an effective vector for permanent service disruption in embedded environments."
}