Received-SPF: pass (google.com: domain of linux-kernel+bounces-162363-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Mon, 29 Apr 2024 09:25:29 -0400
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: shiming.cheng@mediatek.com, 
 willemdebruijn.kernel@gmail.com, 
 edumazet@google.com, 
 davem@davemloft.net, 
 kuba@kernel.org, 
 pabeni@redhat.com, 
 matthias.bgg@gmail.com
Cc: linux-kernel@vger.kernel.org, 
 netdev@vger.kernel.org, 
 shiming.cheng@mediatek.com, 
 Lena Wang <lena.wang@mediatek.com>
Message-ID: <662f9fc92a908_2e2f1d294c2@willemb.c.googlers.com.notmuch>
In-Reply-To: <20240428143010.18719-1-shiming.cheng@mediatek.com>
References: <20240428143010.18719-1-shiming.cheng@mediatek.com>
Subject: Re: [PATCH net] net: drop pulled SKB_GSO_FRAGLIST skb
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: 7bit

shiming.cheng@ wrote:
> From: Shiming Cheng <shiming.cheng@mediatek.com>
> 
> A SKB_GSO_FRAGLIST skb without GSO_BY_FRAGS is
> expected to have all segments except the last
> to be gso_size long. If this does not hold, the
> skb has been modified and the fraglist gso integrity
> is lost. Drop the packet, as it cannot be segmented
> correctly by skb_segment_list.
> 
> The skb could be salvaged. By linearizing, dropping
> the SKB_GSO_FRAGLIST bit and entering the normal
> skb_segment path rather than the skb_segment_list path.
> 
> That choice is currently made in the protocol caller,
> __udp_gso_segment. It's not trivial to add such a
> backup path here. So let's add this backstop against
> kernel crashes.
> 
> Fixes: 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.")
> Signed-off-by: Shiming Cheng <shiming.cheng@mediatek.com>
> Signed-off-by: Lena Wang <lena.wang@mediatek.com>

Reviewed-by: Willem de Bruijn <willemb@google.com>