RE: [PATCH net-next v2 2/5] ipv6: ndisc: Add ndisc_check_ns_na() validation helper

> -----Original Message-----
> From: Danielle Ratson <[email protected]>
> Sent: Monday, 3 August 2026 14:25
> To: [email protected]
> Cc: [email protected]; Ido Schimmel <[email protected]>;
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]; [email protected]; Petr
> Machata <[email protected]>; [email protected]; [email protected];
> [email protected]; [email protected]; Danielle Ratson
> <[email protected]>
> Subject: [PATCH net-next v2 2/5] ipv6: ndisc: Add ndisc_check_ns_na()
> validation helper
> 
> Add ndisc_check_ns_na(), a standalone NS/NA packet validator modeled after
> ipv6_mc_check_mld(). It performs the RFC 4861 section 7.1.1 (Neighbor
> Solicitation) and 7.1.2 (Neighbor Advertisement) mandatory checks that are
> relevant for software operating at the bridge level, where packets bypass the
> normal IPv6 stack path:
> 
>  - Hop Limit must be 255 (packet was not forwarded by a router)
>  - ICMPv6 checksum is valid
>  - ICMP Code is 0
>  - ICMP length is at least 24 octets (sizeof(struct nd_msg))
>  - Target Address must not be a multicast address
>  - All included options have a length that is greater than zero
>  - NS/DAD: destination must be a solicited-node multicast address
>  - NS/DAD: no Source Link-Layer Address option when source is unspecified
>  - NA: Solicited flag must be 0 when IP Destination is multicast
> 
> On success the function sets the skb transport header and returns 0, matching
> the convention of ipv6_mc_check_mld().
> 
> Reviewed-by: Petr Machata <[email protected]>
> Acked-by: Nikolay Aleksandrov <[email protected]>
> Signed-off-by: Danielle Ratson <[email protected]>
> ---

Sashiko wrote:

" 
--- Patch [2]: [PATCH net-next v2 2/5] ipv6: ndisc: Add ndisc_check_ns_na() validation helper ---
commit 4031e051060238d9c59321eb3171c00634174182
Author: Danielle Ratson <[email protected]>
ipv6: ndisc: Add ndisc_check_ns_na() validation helper
This commit adds ndisc_check_ns_na(), a standalone validator for IPv6
Neighbor Solicitation and Neighbor Advertisement packets. It performs
mandatory RFC 4861 checks for software operating at the bridge level.
> diff --git a/net/ipv6/ndisc_snoop.c b/net/ipv6/ndisc_snoop.c
> new file mode 100644
> index 0000000000000..fa86528d5cfee
> --- /dev/null
> +++ b/net/ipv6/ndisc_snoop.c
> @@ -0,0 +1,190 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <linux/skbuff.h>
> +#include <net/addrconf.h>
> +#include <net/ip6_checksum.h>
> +#include <net/ipv6.h>
> +#include <net/ndisc.h>
> +
> +static int ndisc_check_ip6hdr(struct sk_buff *skb)
> +{
> +	const struct ipv6hdr *ip6h;
> +	unsigned int offset, len;
> +
> +	offset = skb_network_offset(skb) + sizeof(*ip6h);
> +	if (!pskb_may_pull(skb, offset))
> +		return -EINVAL;
> +
> +	ip6h = ipv6_hdr(skb);
> +
> +	if (ip6h->version != 6)
> +		return -EINVAL;
> +
> +	if (ip6h->nexthdr != IPPROTO_ICMPV6)
> +		return -ENOMSG;

Does this strict check allow attackers to bypass bridge-level ND security
mechanisms using IPv6 extension headers?
If a spoofed Neighbor Solicitation or Advertisement packet is sent with a
valid IPv6 extension header (like Destination Options), this check will 
return -ENOMSG. A bridge would then likely treat the packet as a non-ND
message and forward it normally, bypassing security mechanisms like
ND snooping or anti-spoofing.
The target host's IPv6 stack will traverse the extension headers and
successfully process the malicious ND payload. Should this use
ipv6_skip_exthdr() to properly traverse to the ICMPv6 header instead?
"

The callers only reach this after checking ipv6_hdr(skb)->nexthdr == IPPROTO_ICMPV6, so a packet with an extension header (nexthdr != ICMPV6) never gets here in the first place.
And if such a packet were ever skipped, it's just not suppressed and floods normally (the default without this feature), so there's no bypass.