Re: [PATCH net-next] net:prevent shared skb corruption on rx-gro-list segmentation

["Lena Wang (王娜)" <Lena.Wang@mediatek.com>]

On Fri, 2023-10-27 at 14:39 +0200, Eric Dumazet wrote:
> > In some scenarios the GRO-ed skb shared with multi users. This
> > segmentation touches the shared heads which sets frag_list to null.
> > After linearization the skb->next is null which results the
> corruption.
> 
> What scenarios would do that ?
> 
> Packets sent to ndo_start_xmit() are not supposed to be shared. (with
> pktgen exception, which is well understood)
> 
> A driver wants to be able to overwrite parts of skb (skb->next and
> many other fields), this is not specific to GSO
> 
> A real fix (if needed) would probably be elsewhere.
> 
This crashed skb's useer count=2 is added in the last line of
skb_segment_list: skb_get(skb). As it is crashed before it runs to
consume_skb, it is wrong about my shared_skb guess.


> >
> > So for shared skb, it needs to clone first than unclone with header
> and
> > data separated for different devices.
> >
> > Signed-off-by: lena wang <lena.wang@mediatek.com>
> 
> Why targeting net-next ?
> 
I am not familiar with tag used. sorry.

This issue is related with patch: [PATCH] net: fix NULL pointer in
skb_segment_list
https://lore.kernel.org/all/Y9gt5EUizK1UImEP@debian/

ZhaiYan told me in mail the problem she encountered is releated to BPF
decapsulation and misconfiguration, where UDP packets from a GUE tunnel
triggered the crash:GRO merges the GUE packets as data and a BPF
program pulls off the GUE header at tc. Since in this case the inner IP
header's total length is not touched by GRO, after decapsulation the
head skb becomes inconsistent with the real total length of GRO chain.
ip_rcv_core then thinks this packet is too long and trim it to fit,
which inherently drops frag_list.
Furthermore there are several locations that may alter the packet
layout, like pskb_pull_tail. It can happen when skb->len mismatches
iphdr->tot_len, for example.


With zhaiyan's patch when in this scenario skb's frag_list is null, it
will be a skb with skb->next=null when skb_segment_list is finished.

Then crash moves into __udp_gso_sement_list -> skb_segment_list(finish)
-> __udpv4_gso_segment_list_csum, it uses skb->next without check then
crash.

Whether do we need to implement here to ignere it?


Thanks
Lena