CVE-2026-14697: IPv6 Neighbor Solicitation packet leak causes TX pool exhaustion denial of service

netipv6sendns() in subsys/net/ip/ipv6nbr.c allocates a transmit netpkt for a Neighbor Solicitation. When it is called with a data packet pending on an unresolved neighbor and that neighbor's pendingqueue is already non-empty (an NS is already outstanding), the function appends the data packet and returns early without ever sending the NS via netsenddata() or releasing it with netpktunref(). The freshly allocated NS netpkt and its attached TX buffers are held only by a local variable and are leaked permanently, never returning to CONFIGNETPKTTXCOUNT / CONFIGNETBUFTXCOUNT.

The leaking branch sits on the normal IPv6 transmit path: netipv6prepareforsend() (called from netif.c) invokes netipv6sendns() 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 CONFIGNETPKTTXCOUNT 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 netpktunref(pkt) before the early return.