Zephyr RTOS EUVD-2026-97113

Requires the Zephyr IPv6 stack with a neighbor cache enabled; CONFIG_NET_IPV6_ROUTE is on by default whenever the IPv6 neighbor cache is, so NO router or forwarding configuration is needed. The attacker must be on the same link (AV:A, adjacent) and unauthenticated (PR:N), and must first drive a neighbor into the unresolved state - either by eliciting traffic to a spoofed non-existent neighbor (creating an INCOMPLETE entry via net_ipv6_send_ns) or by sending a Router Advertisement with no source link-layer address option (creating a persistently unresolved router neighbor) - then send a unicast packet whose destination is that neighbor and not a local address on the receiving interface. The concrete outcome is gated by build configuration: CONFIG_ASSERT enabled yields a guaranteed panic/DoS, while CONFIG_ASSERT disabled yields the bounded ~8-byte static-RAM information disclosure. Limiting factors: local-link adjacency only (not routable/internet-reachable), impact offset is fixed and not attacker-controlled, leak length is capped and gated by the NET_LINK_ADDR_MAX_LENGTH check, and there is no out-of-bounds write.

The input CVSS 3.1 vector (AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H = 7.1 High) is internally consistent with the description: exploitation requires an attacker on the same link (adjacent, not full network/internet reach), no authentication (PR:N), and no user interaction, with the primary impact being a repeatable remote denial of service (A:H) and a secondary limited information disclosure (C:L). My independent assessment agrees with this vector. No EPSS score was provided, and the vulnerability is NOT in CISA KEV, so exploitation status is 'no public exploit identified at time of analysis' - there is no evidence of active exploitation or public POC. SSVC-style reasoning: technical impact is partial (bounded - no OOB write, offset is not attacker-controlled, leak is capped at ~8 bytes of non-attacker-chosen static RAM), and the attack is only partially automatable because it is constrained to the local link. The realistic priority is MODERATE and heavily deployment-dependent: the AV:A adjacency requirement means this is not internet-wide mass-exploitable, so it matters most for embedded/IoT devices exposed to untrusted local networks (shared Wi-Fi, field buses, hostile LAN segments). The DoS branch (CONFIG_ASSERT enabled, the common debug/safety build) is trivially reliable; the info-leak branch (assertions disabled) is lower-value and uncontrolled. This is a legitimately patchable High-severity local-link issue, not an overstated high-CVSS/low-real-risk case, but it is not a drop-everything internet-facing emergency either.

An attacker sharing the local link with a Zephyr-based device sends a Router Advertisement with no source link-layer address option (or elicits traffic to a spoofed non-existent neighbor so a Neighbor Solicitation creates an INCOMPLETE cache entry), leaving a neighbor persistently unresolved with idx == NET_NBR_LLADDR_UNKNOWN (0xff). The attacker then sends a unicast IPv6 packet destined to that neighbor address, reaching net_route_ipv6_packet(), which calls net_nbr_get_lladdr(0xff) and reads ~2.5 KB past the neighbor link-layer array. On CONFIG_ASSERT builds the device panics (reliable remote DoS); with assertions disabled, up to 8 bytes of unrelated static RAM may be copied into an outgoing frame and leaked on the link. No public exploit code was identified at time of analysis.