Description

net_route_ipv6_packet() in subsys/net/ip/route_ipv6.c resolved the nexthop's link-layer address with net_nbr_get_lladdr(nbr->idx) without first checking whether the neighbor cache entry actually had a linked link-layer address. An unresolved neighbor carries idx == NET_NBR_LLADDR_UNKNOWN (0xff), and net_nbr_get_lladdr() in subsys/net/ip/nbr.c performs no runtime bounds check beyond a NET_ASSERT, returning &net_neighbor_lladdr[255] — roughly 2.5 KB past the end of an array whose default size is CONFIG_NET_IPV6_MAX_NEIGHBORS (8). Because the returned pointer is never NULL, the following lladdr == NULL guard does not catch it. The function is reached from ipv6_route_packet() in subsys/net/ip/ipv6.c for every received unicast IPv6 packet whose destination is not a local address on the receiving interface; CONFIG_NET_IPV6_ROUTE is enabled by default whenever the IPv6 neighbor cache is, so no router or forwarding configuration is needed. net_route_ipv6_get_info() returns the packet's destination itself as the nexthop when a neighbor cache entry for it exists, and the cache lookup does not skip INCOMPLETE entries. An unauthenticated attacker on the same link can therefore force the unresolved state — for example by eliciting traffic to a spoofed, non-existent neighbor address so that net_ipv6_send_ns() creates an INCOMPLETE entry, or by sending a Router Advertisement with no source link-layer address option, which creates a persistently unresolved router neighbor — and then send a packet addressed to that neighbor. The result is an out-of-bounds read at a fixed index past the neighbor link-layer address array. On builds with CONFIG_ASSERT enabled the assertion fires and the device panics, giving a repeatable remote denial of service. With assertions disabled, the stale out-of-bounds struct net_linkaddr drives a memcmp() over an attacker-uninfluenced length and, when its len byte passes the NET_LINK_ADDR_MAX_LENGTH check, up to 8 bytes of unrelated static RAM are copied into the outgoing frame's destination link-layer address and transmitted on the link, disclosing them to any listener. There is no out-of-bounds write and the offset is not attacker-controlled, which bounds the impact.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-10-11T18:16:58.433Z",
  "pubdate": "2026-10-11T18:16:58.433Z",
  "executiveSummary": "This vulnerability is an out-of-bounds (OOB) memory read within the IPv6 routing stack of the Zephyr Project. The flaw exists in net_route_ipv6_packet() where the system fails to validate neighbor cache states before resolving link-layer addresses.\nAn unauthenticated, local network attacker can trigger this vulnerability by sending specifically crafted IPv6 traffic to cause an INCOMPLETE neighbor cache entry, leading to an OOB read of static RAM.\nThe impact depends on system configuration: if assertions are enabled, the device enters a panic state resulting in a denial-of-service (DoS). If assertions are disabled, the system performs an unauthorized memory leak, transmitting up to 8 bytes of adjacent static RAM contents over the network interface.\nThe vulnerability is exploitable without authentication and does not require elevated privileges, provided the attacker has link-layer access to the target network. The lack of runtime bounds checking on neighbor indices facilitates the memory access, though the lack of attacker-controlled write capability limits the scope primarily to information disclosure or system instability.",
  "technicalDetails": "The root cause of this vulnerability lies in the function net_route_ipv6_packet() located in subsys/net/ip/route_ipv6.c. This function resolves a nexthop's link-layer address using net_nbr_get_lladdr(nbr->idx) without confirming the validity of the neighbor cache entry state.\nSpecifically, an unresolved neighbor entry possesses an index of NET_NBR_LLADDR_UNKNOWN (0xff). The helper function net_nbr_get_lladdr() in subsys/net/ip/nbr.c relies solely on a NET_ASSERT macro for validation and lacks a runtime bounds check. When passed 0xff, it calculates an address for net_neighbor_lladdr[255], which points to a memory location approximately 2.5 KB beyond the allocated array bounds of the neighbor table.\nThe attack flow begins when an attacker forces a target device into a state where an IPv6 neighbor entry remains in an INCOMPLETE state. This can be achieved by sending traffic to a non-existent neighbor address or by utilizing a Router Advertisement that lacks a source link-layer address option. Once the neighbor entry is persistent and unresolved, the attacker sends a unicast IPv6 packet to that address. The routing logic, specifically ipv6_route_packet() in subsys/net/ip/ipv6.c, reaches the vulnerable code path.\nBecause the function fails to perform a null-check on the returned pointer (which is never NULL due to the arithmetic on a constant base address), the system proceeds to attempt a memcmp() operation. On hardware builds where CONFIG_ASSERT is disabled, the system inadvertently treats the OOB data as a valid struct net_linkaddr. If the 'len' byte within this OOB memory satisfies the NET_LINK_ADDR_MAX_LENGTH threshold, the stack copies up to 8 bytes of adjacent static RAM into the outgoing frame's destination link-layer address field.\nThis results in the unauthorized transmission of memory contents onto the link. If CONFIG_ASSERT is enabled, the NET_ASSERT within net_nbr_get_lladdr() triggers upon the out-of-bounds index, immediately forcing a kernel panic and subsequent denial-of-service. As the offset is fixed and derived from the neighbor cache indexing logic, the attacker cannot influence the specific memory read location, yet the vulnerability consistently leaks sensitive kernel or application memory depending on the memory layout of the static RAM segment."
}