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: <aKANa/mtzIYaCBUb@bhairav-test.ee.iitb.ac.in>
Date: Sat, 16 Aug 2025 10:17:39 +0530
From: Akhilesh Patil <akhilesh@...iitb.ac.in>
To: Alison Schofield <alison.schofield@...el.com>
Cc: saeedm@...dia.com, itayavr@...dia.com, dave.jiang@...el.com,
	jgg@...pe.ca, Jonathan.Cameron@...wei.com,
	linux-kernel@...r.kernel.org, akhileshpatilvnit@...il.com,
	skhan@...uxfoundation.org
Subject: Re: [PATCH] fwctl: mlx5: fix memory alloc/free in mlx5ctl_fw_rpc()

On Fri, Aug 15, 2025 at 11:59:05AM -0700, Alison Schofield wrote:
> On Sun, Aug 10, 2025 at 11:47:42PM +0530, Akhilesh Patil wrote:
> > Use kvfree() to free memory allocated by kvzalloc() instead of kfree().
> > Avoid potential memory management issue by matching alloc/free routines.
> > 
> > Fixes: 52929c2142041 ("fwctl/mlx5: Support for communicating with mlx5 fw")
> > Signed-off-by: Akhilesh Patil <akhilesh@...iitb.ac.in>
> 
> Hi Akhilesh,
> 
> How about making the commit message more specific about why this
> patch is critical even when no immediate symptoms are observed. Based
> on the current description, a developer might think "this works fine
> in my testing, so it's not urgent."
> 
> This type bug is particularly dangerous because it can pass code review
> and testing, then cause mysterious production failures that are extremely
> difficult to trace back to the root cause.

Agree.
> 
> If this sounds like I'm going overboard on an obvious fix, I am doing
> so intentionally. I am encouraging you, as a new contributor, to show
> that you looked into how kvzalloc() works. I believe it can use either
> kmalloc() or vmalloc(). You don't need to be a memory alloc expert to
> submit this fix, but demonstrate that you looked beyond a report in a
> static analysis tool. Also, that's where the interesting learnings
> appear.
> 
> Similar to what Markus mentioned, a simple message stating how this
> was found is useful too.
> 
> --Alison

Thanks Alison for valuable insights and feedback :) 
I will add "How this issue got dicovered" and "Why it is important to
fix" in the commit message and share v2.

Regards,
Akhilesh

> 
> 
> > ---
> >  drivers/fwctl/mlx5/main.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/fwctl/mlx5/main.c b/drivers/fwctl/mlx5/main.c
> > index f93aa0cecdb9..4b379f695eb7 100644
> > --- a/drivers/fwctl/mlx5/main.c
> > +++ b/drivers/fwctl/mlx5/main.c
> > @@ -345,7 +345,7 @@ static void *mlx5ctl_fw_rpc(struct fwctl_uctx *uctx, enum fwctl_rpc_scope scope,
> >  	 */
> >  	if (ret && ret != -EREMOTEIO) {
> >  		if (rpc_out != rpc_in)
> > -			kfree(rpc_out);
> > +			kvfree(rpc_out);
> >  		return ERR_PTR(ret);
> >  	}
> >  	return rpc_out;
> > -- 
> > 2.34.1
> > 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ