On Mon, May 22, 2023 at 07:03:59PM +0200, Pratyush Yadav wrote:
On Mon, May 22 2023, SeongJae Park wrote:
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?
It affects v5.4.243 at least, since that is where I first saw this. But I would expect it to affect other stable kernels it has been backported to as well. I thought using the Fixes tag pointing to the bad upstream commit would be enough for the stable maintainers' tooling/bots to pick this patch up.
In either case, +Cc stable. Link to the patch this thread is talking about [0].
<formletter>
This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.
</formletter>