linux-kernel - Re: [PATCH v2] clk: mvebu/clk-cpu.c: fix memory leakage

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: <20130115182629.GB7211@gmail.com>
Date:	Tue, 15 Jan 2013 19:26:33 +0100
From:	Cong Ding <dinggnu@...il.com>
To:	Gregory CLEMENT <gregory.clement@...e-electrons.com>
Cc:	Jason Cooper <jason@...edaemon.net>,
	Mike Turquette <mturquette@...com>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	linux-kernel@...r.kernel.org,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2] clk: mvebu/clk-cpu.c: fix memory leakage

On Tue, Jan 15, 2013 at 05:33:57PM +0100, Gregory CLEMENT wrote:
> On 01/15/2013 04:37 PM, Jason Cooper wrote:
> > Mike,
> > 
> > On Tue, Jan 15, 2013 at 03:23:08PM +0000, Cong Ding wrote:
> >> From 75c73077905b822be6e8a32a09d6b0cdb5e61763 Mon Sep 17 00:00:00 2001
> >> From: Cong Ding <dinggnu@...il.com>
> >> Date: Mon, 14 Jan 2013 18:06:26 +0100
> >> Subject: [PATCH v2] clk: mvebu/clk-cpu.c: fix memory leakage
> >>
> >> the variable cpuclk and clk_name should be properly freed when error happens.
> >>
> >> Signed-off-by: Cong Ding <dinggnu@...il.com>
> >> ---
> >>  drivers/clk/mvebu/clk-cpu.c |   15 ++++++++++-----
> >>  1 file changed, 10 insertions(+), 5 deletions(-)
> > 
> > 
> > Do you want to take this fix through the clock tree?  If so,
> > 
> > Acked-by: Jason Cooper <jason@...edaemon.net>
> > 
> 
> I also think it should go through the clock tree but before this
> I'd like we fix the last issue.
> 
> Cong Ding,
> 
> you didn't take in account the case when the allocation of the 1st clocks
> when the 2nd cpu clock failed. In this case there is still a memory leak with
> the clock_name of the first cpu clock. See below for my proposal:
> 
> > Otherwise, just let me know.
> > 
> > thx,
> > 
> > Jason.
> > 
> >> diff --git a/drivers/clk/mvebu/clk-cpu.c b/drivers/clk/mvebu/clk-cpu.c
> >> index ff004578..1066a43 100644
> >> --- a/drivers/clk/mvebu/clk-cpu.c
> >> +++ b/drivers/clk/mvebu/clk-cpu.c
> >> @@ -124,7 +124,7 @@ void __init of_cpu_clk_setup(struct device_node *node)
> >>  
> >>  	clks = kzalloc(ncpus * sizeof(*clks), GFP_KERNEL);
> >>  	if (WARN_ON(!clks))
> >> -		return;
> >> +		goto clks_out;
> >>  
> >>  	for_each_node_by_type(dn, "cpu") {
> >>  		struct clk_init_data init;
> >> @@ -134,11 +134,13 @@ void __init of_cpu_clk_setup(struct device_node *node)
> >>  		int cpu, err;
> >>  
> >>  		if (WARN_ON(!clk_name))
> >> -			return;
> >> +			goto bail_out;
> >>  
> >>  		err = of_property_read_u32(dn, "reg", &cpu);
> >> -		if (WARN_ON(err))
> >> -			return;
> >> +		if (WARN_ON(err)) {
> 
> >> +			kfree(clk_name);
> we can free it later
> 
> >> +			goto bail_out;
> >> +		}
> >>  
> >>  		sprintf(clk_name, "cpu%d", cpu);
> >>  		parent_clk = of_clk_get(node, 0);
> >> @@ -156,8 +158,10 @@ void __init of_cpu_clk_setup(struct device_node *node)
> >>  		init.num_parents = 1;
> >>  
> >>  		clk = clk_register(NULL, &cpuclk[cpu].hw);
> >> -		if (WARN_ON(IS_ERR(clk)))
> >> +		if (WARN_ON(IS_ERR(clk))) {
> 
> >> +			kfree(clk_name);
> we can free it later
> 
> >>  			goto bail_out;
> >> +		}
> >>  		clks[cpu] = clk;
> >>  	}
> >>  	clk_data.clk_num = MAX_CPU;
> >> @@ -167,6 +171,7 @@ void __init of_cpu_clk_setup(struct device_node *node)
> >>  	return;
> >>  bail_out:
> >>  	kfree(clks);
> >> +clks_out:
> 
> as cpuclk is allocated with all its member set to 0, and kfree(0) is a valid call.
> We can add the following lines:
> while(ncpus--)
> 	kfree(cpuclk[ncpus].clk_name);
> 
> >>  	kfree(cpuclk);
> >>  }
I agree the version 2 patch still includes memory leakage in terms of clk_name,
but I am wondering whether it is safe to call kfree(cpuclk[ncpus].clkname)
directly or not. It's true that kfree(0) is valid, but cpuclk[ncpus].clkname
might not be 0 when it is allocated by kzalloc. kzalloc just allocates the
memory while doesn't ensure the initial value in this memory area is 0. So I
am thinking we should call memset after the alloction or use a counter to
remember the number of clk_names allocated?

- cong

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/