> -----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.
