CVE-2026-19577: Out-of-bounds read in IPv6 route forwarding when the nexthop neighbor has no link-layer address

Published Oct 11, 2026
·
Updated

netrouteipv6packet() in subsys/net/ip/routeipv6.c resolved the nexthop's link-layer address with netnbrgetlladdr(nbr->idx) without first checking whether the neighbor cache entry actually had a linked link-layer address. An unresolved neighbor carries idx == NETNBRLLADDRUNKNOWN (0xff), and netnbrgetlladdr() in subsys/net/ip/nbr.c performs no runtime bounds check beyond a NETASSERT, returning &netneighborlladdr[255] — roughly 2.5 KB past the end of an array whose default size is CONFIGNETIPV6MAXNEIGHBORS (8). Because the returned pointer is never NULL, the following lladdr == NULL guard does not catch it.

The function is reached from ipv6routepacket() in subsys/net/ip/ipv6.c for every received unicast IPv6 packet whose destination is not a local address on the receiving interface; CONFIGNETIPV6ROUTE is enabled by default whenever the IPv6 neighbor cache is, so no router or forwarding configuration is needed. netrouteipv6getinfo() 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 netipv6sendns() 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 CONFIGASSERT enabled the assertion fires and the device panics, giving a repeatable remote denial of service. With assertions disabled, the stale out-of-bounds struct netlinkaddr drives a memcmp() over an attacker-uninfluenced length and, when its len byte passes the NETLINKADDRMAXLENGTH 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.

Affected Software

1 affected component
Zephyr Project Zephyr RTOS

Event History

Oct 11, 2026
CVE Published
via MITRE·05:14 PM
Data Sourced
via MITRE·05:14 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·06:16 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which deployments are exposed without explicitly enabling routing?

Devices with the IPv6 neighbor cache enabled are exposed because CONFIG_NET_IPV6_ROUTE is enabled by default in that configuration. No router role or forwarding configuration is required.

2

What access does an attacker need?

An unauthenticated attacker needs to be on the same network link and able to send unicast IPv6 packets to the device. The destination must not be a local address on the receiving interface.

3

What neighbor-cache state is involved in triggering the issue?

The relevant destination must have a neighbor-cache entry that is still unresolved, including an INCOMPLETE entry. Such an entry has no linked link-layer address and uses the unknown index value 0xff, which leads to an out-of-bounds lookup.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203