Re: [PATCH net 1/1] ipv6: orphan prefetched skb before ip6_mr_input

On Mon, Aug 03, 2026 at 10:47:10AM +0800, Zhiling Zou wrote:
> ip6_rcv_core() keeps skb->sk alive when it was installed by early
> demux with sock_pfree so later receive-side code can use the prefetched
> socket under RCU. ip6_mc_input() breaks that assumption in the
> deliver == false path by handing the original skb to ip6_mr_input(),
> which can queue or forward it after the receive-side RCU section ends.

I don't understand the part about ip6_rcv_core(). Early demux happens
only later, in ip6_rcv_finish_core().

> 
> A UDPv6 early-demuxed multicast packet that is not locally deliverable
> but still enters multicast forwarding can therefore carry a dangling
> socket pointer into unresolved mroute cleanup and later hit
> sock_pfree() after the matched socket has already been destroyed.

It's unclear how an IP multicast packet gets into UDP early demux which
checks for PACKET_HOST. The commit message should mention that the
reproducer sends a packet with a unicast destination MAC and a multicast
IP:

rx_mac = get_hwaddr(IF_RX)
tx_mac = get_hwaddr(IF_TX)
[...]
src_ip = ipaddress.IPv6Address(SRC_ADDR).packed
group_ip = ipaddress.IPv6Address(GROUP).packed
[...]
ipv6_hdr = struct.pack("!IHBB16s16s", (6 << 28), udp_len, socket.IPPROTO_UDP, 64, src_ip, group_ip)
eth_hdr = rx_mac + tx_mac + struct.pack("!H", 0x86DD)
frame = eth_hdr + ipv6_hdr + udp_hdr + payload

> 
> Orphan the original skb before giving it to ip6_mr_input() when there
> is no local delivery. The deliver == true path already uses
> skb_clone(), which clears skb->sk and the destructor state.
> 
> Fixes: cf7fbe660f2d ("bpf: Add socket assign support")

The reproducer doesn't use BPF at all. I think it only triggers the
problem after commit 08842c43d016 ("udp: no longer touch sk->sk_refcnt
in early demux"). So, blame both, but mention that the problem can also
be triggered in the bpf_sk_assign() path.

> Cc: [email protected]
> Reported-by: Vega <[email protected]>
> Signed-off-by: Zhiling Zou <[email protected]>

More feedback from Sashiko:

https://sashiko.dev/#/patchset/02db4590d0161e31a789dcdfa8d1be1a3212ec2e.1785724784.git.zhilinz%40nebusec.ai
https://netdev-ai.bots.linux.dev/sashiko/#/patchset/02db4590d0161e31a789dcdfa8d1be1a3212ec2e.1785724784.git.zhilinz%40nebusec.ai

I couldn't get myself to read all of it, but it does seem like IPv4
suffers from the same problem.