linux-kernel - Re: [PATCH] platform/x86/amd: Fix memory leak in wbrf

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <df87cb9d-467b-e9bd-52d6-5ca4f0c1137a@linux.intel.com>
Date: Fri, 2 Jan 2026 13:29:20 +0200 (EET)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Zilin Guan <zilin@....edu.cn>
cc: Hans de Goede <hansg@...nel.org>, jianhao.xu@....edu.cn, 
    LKML <linux-kernel@...r.kernel.org>, platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH] platform/x86/amd: Fix memory leak in wbrf_record()

On Tue, 30 Dec 2025, Zilin Guan wrote:
> On Tue, Dec 30, 2025 at 09:51:06AM+0100, Markus Elfring wrote:
> > …
> > > Fix this by adding a free_tmp label and jumping to it when obj is NULL,
> > > ensuring tmp is properly freed.
> > 
> > How do you think about to increase the application of scope-based 
> > resource management? 
> > 
> > Regards,
> > Markus
> 
> Thanks for the suggestion.
> 
> While scope-based resource management is a valid improvement, I prefer to 
> keep this patch focused solely on fixing the memory leak using the 
> existing coding style of the file. This ensures the fix is minimal and 
> easier to backport.
> 
> Such refactoring is arguably outside the scope of this fix.

Hi,

Lets not get too attached to the ways of the past, using __free() is
what we want to use even as a fix here. Adding goto labels adds 
complexity, not reduces it, so I don't buy the easier backport argument
(on backport each goto target should be carefully reviewed which is 
something __free() does not require because it simply is better 
interface).

You just need to remember to move also the variable declaration down to 
the alloc site as per the guidance in cleanup.h.

-- 
 i.