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: <699aa920-ac7a-43ef-8ad5-5157d0018b54@gmail.com>
Date: Fri, 24 Oct 2025 15:48:44 +0100
From: Edward Cree <ecree.xilinx@...il.com>
To: Jacob Keller <jacob.e.keller@...el.com>,
 Abdun Nihaal <nihaal@....iitm.ac.in>
Cc: andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
 kuba@...nel.org, pabeni@...hat.com, habetsm.xilinx@...il.com,
 alejandro.lucero-palau@....com, netdev@...r.kernel.org,
 linux-net-drivers@....com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 net] sfc: fix potential memory leak in
 efx_mae_process_mport()

On 24/10/2025 01:48, Jacob Keller wrote:
> On 10/23/2025 7:18 AM, Abdun Nihaal wrote:
>> In efx_mae_enumerate_mports(), memory allocated for mae_mport_desc is
>> passed as a argument to efx_mae_process_mport(), but when the error path
>> in efx_mae_process_mport() gets executed, the memory allocated for desc
>> gets leaked.
>>
>> Fix that by freeing the memory allocation before returning error.
> 
> Why not make the caller responsible for freeing desc on failure?

Since the callee takes ownership of desc on success (it stashes it in a
 table), arguably it's cleaner to have it do so in all cases; it's an
 aesthetic judgment call but I think I'd rather keep it this way and just
 fix this one failure path than change all the existing failure paths and
 the caller.
Alejandro (original author of this code) might have a different opinion
 in which case I'll defer to him but otherwise I'd say v2 is fine to apply
 as-is.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ