[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iLNACt6vh5OAjDmRxpQ3-DkuUP_Vfh9AZGpGinzwJ-1dw@mail.gmail.com>
Date: Thu, 31 Aug 2023 10:47:21 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Mohamed Khalfella <mkhalfella@...estorage.com>
Cc: willemdebruijn.kernel@...il.com, alexanderduyck@...com,
bpf@...r.kernel.org, brouer@...hat.com, davem@...emloft.net,
dhowells@...hat.com, keescook@...omium.org, kuba@...nel.org,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
pabeni@...hat.com, willemb@...gle.com, stable@...r.kernel.org
Subject: Re: [PATCH v3] skbuff: skb_segment, Call zero copy functions before
using skbuff frags
On Thu, Aug 31, 2023 at 10:17 AM Mohamed Khalfella
<mkhalfella@...estorage.com> wrote:
>
> Commit bf5c25d60861 ("skbuff: in skb_segment, call zerocopy functions
> once per nskb") added the call to zero copy functions in skb_segment().
> The change introduced a bug in skb_segment() because skb_orphan_frags()
> may possibly change the number of fragments or allocate new fragments
> altogether leaving nrfrags and frag to point to the old values. This can
> cause a panic with stacktrace like the one below.
>
>
> In this case calling skb_orphan_frags() updated nr_frags leaving nrfrags
> local variable in skb_segment() stale. This resulted in the code hitting
> i >= nrfrags prematurely and trying to move to next frag_skb using
> list_skb pointer, which was NULL, and caused kernel panic. Move the call
> to zero copy functions before using frags and nr_frags.
>
> Fixes: bf5c25d60861 ("skbuff: in skb_segment, call zerocopy functions once per nskb")
> Signed-off-by: Mohamed Khalfella <mkhalfella@...estorage.com>
> Reported-by: Amit Goyal <agoyal@...estorage.com>
> Cc: stable@...r.kernel.org
> ---
Reviewed-by: Eric Dumazet <edumazet@...gle.com>
Powered by blists - more mailing lists