Re: [PATCH net v2 1/1] ip: orphan prefetched skbs before multicast forwarding

Ido Schimmel <[email protected]>
Newsgroups org.kernel.vger.netdev,org.kernel.vger.bpf
Message-ID <20260810152327.GA2779332@shredder>
On Thu, Aug 06, 2026 at 11:18:56PM +0800, Zhiling Zou wrote:
> IPv4 and IPv6 input preserve an skb->sk association installed by
> bpf_sk_assign() so that local delivery can use the selected socket under
> RCU. IPv6 can also get such an association from udp_v6_early_demux(),
> which runs in ip6_rcv_finish_core(), after ip6_rcv_core().

Last sentence is not accurate since it doesn't cover IPv4 which is also
fixed here. I suggest something like:

"Both address families can also prefetch a socket in UDP early demux. In
both paths (BPF and UDP early demux) a reference is not guaranteed to be
held on the socket."

> 
> The reproduced UDPv6 packet has a multicast IP destination but a unicast
> destination MAC address. It is therefore classified as PACKET_HOST and
> passes the UDP early-demux check.

This is again specific to IPv6 although IPv4 suffers from the same
problem. I think we can drop this paragraph.

> 
> When the multicast packet is not locally deliverable, IPv6 hands the

s/When the/When a/

> original skb to ip6_mr_input(). IPv4's ip_mr_input() similarly keeps the
> original skb when local delivery is not needed. Either path can put the
> skb on an unresolved multicast route queue or forward it after the
> receive-side RCU section ends.
> 
> After the prefetched socket is destroyed, a later skb free invokes
> sock_pfree() and dereferences the stale skb->sk. Orphan the skb before
> each non-local multicast forwarding path. Local delivery retains the
> original skb; the existing skb_clone() calls provide multicast forwarding
> with a socket-free clone.
> 
> Fixes: cf7fbe660f2d ("bpf: Add socket assign support")
> Fixes: 08842c43d016 ("udp: no longer touch sk->sk_refcnt in early demux")
> Cc: [email protected]
> Reported-by: Vega <[email protected]>
> Signed-off-by: Zhiling Zou <[email protected]>

The rest looks fine to me.

Both sashikos mention other possible instances of the bug, but I believe
they require bpf_sk_assign(), unlike UDP early demux which is used here.
Assuming these issues are real and reproducible, they should be fixed in
a separate patchset.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.