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.
Published: 2026-08-31
Score: 6.5 Medium
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability lies in the IPv6 Neighbor Solicitation handling where a transmit packet is leaked when an unresolved neighbor has a pending queue. The leak causes a permanent drain of the transmit buffer pool, effectively blocking all outgoing traffic including TCP/UDP, ARP, and ND responses. The impact is a persistent network denial of service that does not recover until the system reboots. This weakness corresponds to missing resource release (CWE‑401).

Affected Systems

This issue affects systems running the Zephyr RTOS, specifically the network subsystem in zephyr:zephyr. The affected component is the IPv6 neighbor solicitation logic in subsys/net/ip/ipv6_nbr.c, which is part of the Zephyr networking stack. No specific hardware or configuration versions are listed beyond the default Zephyr configuration, though systems with the default CONFIG_NET_PKT_TX_COUNT of 4 (or 14 on Ethernet) are at risk.

Risk and Exploitability

The vulnerability has a CVSS score of 6.5 and is not listed in the CISA KEV catalog. The EPSS score is not available, indicating insufficient data on exploit probability. The exploit can be triggered deterministically by a local or on‑link attacker who sends a burst of packets that all spoof the same nonexistent on‑link source address. When the neighbor resolution process is invoked for each packet, the governed branch permanently leaks transmit buffers, draining the pool within a short burst. Because the condition is tied to the neighbor resolution timer and network traffic, an attacker can repeatedly exercise the code path in a short timeframe. The resulting denial lasts for the lifetime of the device until a reboot occurs, unless mitigated by configuration changes or firmware updates. The absence of self‑healing means the risk is ongoing until remediation is applied.

Generated by OpenCVE AI on August 31, 2026 at 20:21 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the Zephyr patch that releases the unsent Neighbor Solicitation packet before the early return (commit ab2670e8b5b8fcde4a699dd5cbe452abbd233289).
  • Rebuild the Zephyr firmware with the updated source and flash the new image to all affected devices. This ensures the corrected logic is in the running kernel.
  • As a temporary measure, increase CONFIG_NET_PKT_TX_COUNT to a larger value to raise the TX buffer pool size, which reduces the likelihood of exhaustion while the patch is being rolled out.

Generated by OpenCVE AI on August 31, 2026 at 20:21 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Mon, 31 Aug 2026 20:45:00 +0000

Type Values Removed Values Added
First Time appeared Zephyrproject
Zephyrproject zephyr
Vendors & Products Zephyrproject
Zephyrproject zephyr

Mon, 31 Aug 2026 19:45:00 +0000

Type Values Removed Values Added
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.
Title IPv6 Neighbor Solicitation packet leak causes TX pool exhaustion denial of service
Weaknesses CWE-401
References
Metrics cvssV3_1

{'score': 6.5, 'vector': 'CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}


Subscriptions

Zephyrproject Zephyr
cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-08-31T19:34:49.586Z

Reserved: 2026-07-04T05:18:35.366Z

Link: CVE-2026-14697

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-31T20:17:03.253

Modified: 2026-08-31T20:17:03.253

Link: CVE-2026-14697

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-31T20:30:05Z

Weaknesses
  • CWE-401

    Missing Release of Memory after Effective Lifetime