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: <50F5A1A9.2030803@free-electrons.com>
Date:	Tue, 15 Jan 2013 19:36:25 +0100
From:	Gregory CLEMENT <gregory.clement@...e-electrons.com>
To:	Cong Ding <dinggnu@...il.com>
CC:	Jason Cooper <jason@...edaemon.net>,
	Mike Turquette <mturquette@...aro.org>,
	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 01/15/2013 07:26 PM, Cong Ding wrote:
> 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

I think that you describe the behavior of kmalloc, but the main difference
with kmalloc and kzalloc, is that kzalloc allocates _zeroed_ paged, so I am
pretty sure that all the memory space allocated should be set to zero.

> am thinking we should call memset after the alloction or use a counter to
> remember the number of clk_names allocated?
> 
> - cong
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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/