Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   SeongJae Park <sj@kernel.org>
To:     SeongJae Park <sj@kernel.org>
Cc:     Kuniyuki Iwashima <kuniyu@amazon.com>, davem@davemloft.net,
        edumazet@google.com, kuba@kernel.org, linux-kernel@vger.kernel.org,
        netdev@vger.kernel.org, nmanthey@amazon.de, pabeni@redhat.com,
        ptyadav@amazon.de, willemb@google.com
Subject: Re: [PATCH net] net: fix skb leak in __skb_tstamp_tx()
Date:   Mon, 22 May 2023 17:33:51 +0000
Message-Id: <20230522173351.90497-1-sj@kernel.org>
In-Reply-To: <20230522172302.90235-1-sj@kernel.org>
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Mon, 22 May 2023 17:23:02 +0000 SeongJae Park <sj@kernel.org> wrote:

> On Mon, 22 May 2023 17:18:53 +0000 SeongJae Park <sj@kernel.org> wrote:
> 
> > On Mon, 22 May 2023 10:04:30 -0700 Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
> > 
> > > From: SeongJae Park <sj@kernel.org>
> > > Date: Mon, 22 May 2023 16:55:05 +0000
> > > > Hi Pratyush,
> > > > 
> > > > On Mon, 22 May 2023 17:30:20 +0200 Pratyush Yadav <ptyadav@amazon.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@vger.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.
> > 
> > Thank you for the nice explanation!  Seems it is also well documented at
> > https://www.kernel.org/doc/html/v5.10/networking/netdev-FAQ.html#q-i-see-a-network-patch-and-i-think-it-should-be-backported-to-stable
> > 
> > However, I don't show the 'net' subject rule on the document.  Is it documented
> > somewhere else?
> 
> Seems I overlooked this:
> https://www.kernel.org/doc/html/v5.10/networking/netdev-FAQ.html#q-how-do-i-indicate-which-tree-net-vs-net-next-my-patch-should-be-in

Sorry for continuing adding noises, but seems the process is, or will be,
changed by to the mainline commit dbbe7c962c3a8 ("docs: networking: drop
special stable handling").


Thanks,
SJ

[...]