Subject: Re: [PATCH bpf-next v7 2/7] net: move netfilter nf_reject6_fill_skb_dst to core ipv6

From: Mahe Tardy <[email-masked]>
Date: Wed, 27 May 2026 00:02:00 +0200

On Tue, May 26, 2026 at 04:20:14PM +0000, [email-masked] wrote:
> > diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
> > index 09ffe0f13ce7..eb5a60d3babe 100644
> > --- a/include/net/ip6_route.h
> > +++ b/include/net/ip6_route.h
> > @@ -100,6 +100,8 @@ static inline struct dst_entry *ip6_route_output(struct net *net,
> >  	return ip6_route_output_flags(net, sk, fl6, 0);
> >  }
> >
> > +int ip6_route_reply_fill_dst(struct sk_buff *skb);
> > +
> >  /* Only conditionally release dst if flags indicates
> >   * !RT6_LOOKUP_F_DST_NOREF or dst is in uncached_list.
> >   */
> 
> [ ... ]
> 
> > diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> > index b106e5fef9cb..e72065aa5f5a 100644
> > --- a/net/ipv6/route.c
> > +++ b/net/ipv6/route.c
> > @@ -2725,6 +2725,24 @@ struct dst_entry *ip6_route_output_flags(struct net *net,
> >  }
> >  EXPORT_SYMBOL_GPL(ip6_route_output_flags);
> >
> > +int ip6_route_reply_fill_dst(struct sk_buff *skb)
> > +{
> > +	struct dst_entry *result;
> > +	struct flowi6 fl = {
> > +		.daddr = ipv6_hdr(skb)->saddr
> > +	};
> 
> Could ipv6_hdr(skb)->saddr read out-of-bounds memory if the IPv6 header
> spans paged fragments?
> 
> Since this function is exported as EXPORT_SYMBOL_GPL for use by BPF kfuncs,
> it might be called on packets where the header isn't guaranteed to be in
> the linear data area. If there are no linearization checks like
> pskb_may_pull() before accessing ipv6_hdr(), this could read out-of-bounds
> memory or cause a page fault when processing undersized or fragmented
> packets supplied by BPF programs.
> 
> The v6 cover letter mentions "call pskb_network_may_pull on the cloned
> pkt", but this linearization check is not present in this function.
> 
> While the netfilter caller (nf_send_unreach6) may ensure the header is
> linearized, the exported function itself doesn't validate this condition.
> 
> Reference: https://lore.kernel.org/bpf/[email-masked]/

This is the same remark as on IPv4 on which I already responded, I don't
think that's an actual issue.

> 
> > +	int err;
> > +
> > +	result = ip6_route_output(dev_net(skb->dev), NULL, &fl);
> 
> Can skb->dev be NULL in contexts where this function will be used?
> 
> Since this function is exported as EXPORT_SYMBOL_GPL for use by BPF
> kfuncs, it might be called from program types where the device reference
> is not retained, such as socket filters or tc ingress before device
> assignment. If skb->dev is NULL in these contexts, dev_net(skb->dev)
> would cause a NULL pointer dereference.
> 
> While the netfilter caller (nf_send_unreach6) checks and sets skb->dev
> to loopback_dev if NULL, the exported function itself does not have this
> protection.
> 
> Reference: https://lore.kernel.org/bpf/[email-masked]/

Dito.

> 
> > +	err = result->error;
> > +	if (err)
> > +		dst_release(result);
> > +	else
> > +		skb_dst_set(skb, result);
> > +	return err;
> > +}
> > +EXPORT_SYMBOL_GPL(ip6_route_reply_fill_dst);
> > +
> >  struct dst_entry *ip6_blackhole_route(struct net *net, struct dst_entry *dst_orig)
> >  {
> >  	struct rt6_info *rt, *ort = dst_rt6_info(dst_orig);
> 
> 
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> 
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/26459248718