lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20230522170430.56198-1-kuniyu@amazon.com> Date: Mon, 22 May 2023 10:04:30 -0700 From: Kuniyuki Iwashima <kuniyu@...zon.com> To: <sj@...nel.org> 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>, <ptyadav@...zon.de>, <willemb@...gle.com> Subject: Re: [PATCH net] net: fix skb leak in __skb_tstamp_tx() From: SeongJae Park <sj@...nel.org> Date: Mon, 22 May 2023 16:55:05 +0000 > Hi Pratyush, > > On Mon, 22 May 2023 17:30:20 +0200 Pratyush Yadav <ptyadav@...zon.de> wrote: > > > 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.") > > Seems the commit has merged in several stable kernels. Is the bug also > affecting those? If so, would it be better to Cc stable@...r.kernel.org? In netdev, we add 'net' in Subject for bugfix, then netdev maintainers send a pull request weekly, and stable maintainers backport the fixes to affected trees. So we usually need not CC stable for netdev patches. Thanks, Kuniyuki > > > Thanks, > SJ > > > Signed-off-by: Pratyush Yadav <ptyadav@...zon.de> > > --- > > > > 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