| Message ID | a6f256694783a0692f2f079e7ac76ace621308c3.camel@mediatek.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [net-next] net:prevent shared skb corruption on rx-gro-list segmentation | expand |
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
diff --git a/net/core/skbuff.c b/net/core/skbuff.c index b157efea5dea..adeb3ad9697b 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -4351,6 +4351,12 @@ struct sk_buff *skb_segment_list(struct sk_buff *skb, skb_push(skb, -skb_network_offset(skb) + offset); + if (skb_shared(skb)) { + skb = skb_share_check(skb, GFP_ATOMIC); + if (!skb) + goto err_linearize; + } + /* Ensure the head is writeable before touching the shared info */