[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230522154554.44836-1-kuniyu@amazon.com>
Date: Mon, 22 May 2023 08:45:54 -0700
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <ptyadav@...zon.de>
CC: <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
<kuniyu@...zon.com>, <linux-kernel@...r.kernel.org>,
<netdev@...r.kernel.org>, <nmanthey@...zon.de>,
<pabeni@...hat.com>, <willemb@...gle.com>
Subject: Re: [PATCH net] net: fix skb leak in __skb_tstamp_tx()
From: Pratyush Yadav <ptyadav@...zon.de>
Date: Mon, 22 May 2023 17:30:20 +0200
> Commit 50749f2dd685 ("tcp/udp: Fix memleaks of sk and zerocopy skbs with
> TX timestamp.") added a call to skb_orphan_frags_rx() to fix leaks with
> zerocopy skbs. But it ended up adding a leak of its own. When
> skb_orphan_frags_rx() fails, the function just returns, leaking the skb
> it just cloned. Free it before returning.
>
> This bug was discovered and resolved using Coverity Static Analysis
> Security Testing (SAST) by Synopsys, Inc.
>
> Fixes: 50749f2dd685 ("tcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp.")
> Signed-off-by: Pratyush Yadav <ptyadav@...zon.de>
Reviewed-by: Kuniyuki Iwashima <kuniyu@...zon.com>
Good catch, thanks!
> ---
>
> I do not know this code very well, this was caught by our static
> analysis tool. I did not try specifically reproducing the leak but I did
> do a boot test by adding this patch on 6.4-rc3 and the kernel boots
> fine.
>
> net/core/skbuff.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 515ec5cdc79c..cea28d30abb5 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -5224,8 +5224,10 @@ void __skb_tstamp_tx(struct sk_buff *orig_skb,
> } else {
> skb = skb_clone(orig_skb, GFP_ATOMIC);
>
> - if (skb_orphan_frags_rx(skb, GFP_ATOMIC))
> + if (skb_orphan_frags_rx(skb, GFP_ATOMIC)) {
> + kfree_skb(skb);
> return;
> + }
> }
> if (!skb)
> return;
> --
> 2.39.2
Powered by blists - more mailing lists