CVE-2026-7656 in zephyr
Summary
by MITRE • 06/30/2026
The IPv6 Neighbor Discovery handlers in subsys/net/ip/ipv6_nbr.c (handle_ra_input, handle_ns_input, handle_na_input) used an incorrect boolean expression that combined the RFC 4861 validity checks with the ICMPv6 code check using the wrong operator precedence: the form was '((length/hop/source/target checks) && (icmp_hdr-code != 0))'. Because every legitimate ND message carries ICMPv6 code 0, an attacker setting code == 0 (the normal value) caused the entire predicate to evaluate false, so the packet was never dropped and all of the other checks were silently skipped. The bypassed checks include the mandatory Hop Limit == 255 verification (which proves an ND packet originated on-link and was not forwarded) and, for Router Advertisements, the requirement that the source be a link-local address, as well as multicast-target sanity checks. As a result, an adjacent on-link attacker — and, because the Hop-Limit-255 guard is bypassed, potentially a remote/off-link attacker whose packets would otherwise be rejected — can have forged Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages accepted. A forged RA lets the attacker reconfigure the victim's default router, on-link prefixes (SLAAC), MTU, reachable/retransmit timers, and (with CONFIG_NET_IPV6_RA_RDNSS) DNS servers, while forged NS/NA enable neighbor-cache poisoning, enabling man-in-the-middle, traffic redirection, and denial of service. The flaw is an input-validation/authentication weakness rather than a memory-safety issue: the underlying packet-parsing primitives (net_pkt_get_data, net_pkt_read, net_pkt_skip) are independently bounds-safe and the validated 'length' is the true buffer length, so skipping the length check causes no out-of-bounds access. The defect has existed since the logic was introduced in 2018 and shipped in all releases through v4.4.0; it is fixed by splitting the condition so any failing check drops the packet.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 06/30/2026
The vulnerability described represents a critical input validation flaw in the IPv6 Neighbor Discovery protocol implementation within the Zephyr RTOS network subsystem. This issue affects the core neighbor discovery handlers responsible for processing Router Advertisements, Neighbor Solicitations, and Neighbor Advertisements through the ipv6_nbr.c file. The fundamental problem lies in the improper boolean expression construction that combines multiple validity checks with ICMPv6 code verification using incorrect operator precedence. According to the ATT&CK framework, this constitutes a weakness in input validation and authentication mechanisms under the technique T1210 - Exploitation of Remote Services.
The technical flaw manifests when the system evaluates packets using the erroneous predicate '((length/hop/source/target checks) && (icmp_hdr-code != 0))' where the ICMPv6 code check is improperly combined with other validation criteria. Legitimate IPv6 Neighbor Discovery messages always contain an ICMPv6 code of zero, which serves as a fundamental protocol requirement. When attackers craft packets with code zero, the boolean logic fails because the expression evaluates to false, causing all subsequent validation checks to be bypassed entirely. This logical error stems from CWE-703, representing improper handling of exceptional conditions in network protocol parsing. The flaw is particularly dangerous because it undermines several essential security checks that should prevent unauthorized modifications to network configuration.
The operational impact of this vulnerability extends far beyond simple packet rejection. When the Hop Limit validation check is bypassed, attackers can submit packets from off-link sources that would normally be rejected due to the mandatory hop limit of 255 for on-link originated packets. This allows remote attackers to potentially inject malicious neighbor discovery messages into networks where they shouldn't be permitted. The bypassed checks include critical security validations such as source address verification for Router Advertisements, which should require link-local addresses, and multicast target address sanity checking. These failures enable sophisticated attacks including man-in-the-middle positioning, traffic redirection, and denial of service through neighbor cache poisoning operations.
The consequences of successful exploitation are severe and multifaceted according to network security principles. An attacker can forge Router Advertisement messages to modify victim device configurations including default router selection, on-link prefix assignments through SLAAC, MTU settings, and various timing parameters for neighbor discovery. The inclusion of CONFIG_NET_IPV6_RA_RDNSS capability allows attackers to inject malicious DNS server information, potentially redirecting all network traffic through compromised resolvers. Neighbor Solicitation and Advertisement message forgery enables direct neighbor cache poisoning attacks that can disrupt communication channels. These capabilities align with the ATT&CK technique T1562 - Impair Defenses, where network configuration changes can be used to undermine existing security controls. The attack surface is particularly concerning given that this flaw affects all versions through v4.4.0 and has been present since 2018, making it a long-standing vulnerability in widely deployed systems.
The mitigation strategy involves restructuring the validation logic to ensure that any single failing check causes immediate packet rejection rather than allowing subsequent checks to be bypassed due to flawed boolean evaluation. This approach addresses the root cause by implementing proper conditional logic where each individual validation must pass before proceeding to the next check, preventing the cascade of bypassed security measures. The fix specifically targets the boolean expression construction pattern that caused the vulnerability, ensuring that input validation operates as intended and that all required protocol compliance checks are maintained regardless of ICMPv6 code values. This remediation aligns with defensive programming practices and strengthens the overall security posture by preventing the exploitation of logical errors in packet validation mechanisms.