linux-kernel - Re: [PATCH net v2] octeontx2-pf: Fix potential memory leak in otx2_init

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: <206c4fdc-bba2-32e3-8e44-82cad81e0436@huawei.com>
Date:   Mon, 5 Dec 2022 10:31:02 +0800
From:   "Ziyang Xuan (William)" <william.xuanziyang@...wei.com>
To:     Leon Romanovsky <leon@...nel.org>
CC:     <sgoutham@...vell.com>, <gakula@...vell.com>,
        <sbhatta@...vell.com>, <hkelam@...vell.com>, <davem@...emloft.net>,
        <edumazet@...gle.com>, <kuba@...nel.org>, <pabeni@...hat.com>,
        <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net v2] octeontx2-pf: Fix potential memory leak in
 otx2_init_tc()

> On Fri, Dec 02, 2022 at 07:04:30PM +0800, Ziyang Xuan wrote:
>> In otx2_init_tc(), if rhashtable_init() failed, it does not free
>> tc->tc_entries_bitmap which is allocated in otx2_tc_alloc_ent_bitmap().
>>
>> Fixes: 2e2a8126ffac ("octeontx2-pf: Unify flow management variables")
>> Signed-off-by: Ziyang Xuan <william.xuanziyang@...wei.com>
>> ---
>> v2:
>>   - Remove patch 2 which is not a problem, see the following link:
>>     https://www.spinics.net/lists/netdev/msg864159.html
>> ---
>>  drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c | 7 ++++++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
>> index e64318c110fd..6a01ab1a6e6f 100644
>> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
>> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
>> @@ -1134,7 +1134,12 @@ int otx2_init_tc(struct otx2_nic *nic)
>>  		return err;
>>  
>>  	tc->flow_ht_params = tc_flow_ht_params;
>> -	return rhashtable_init(&tc->flow_table, &tc->flow_ht_params);
>> +	err = rhashtable_init(&tc->flow_table, &tc->flow_ht_params);
>> +	if (err) {
>> +		kfree(tc->tc_entries_bitmap);
>> +		tc->tc_entries_bitmap = NULL;
> 
> Why do you set NULL here? All callers of otx2_init_tc() unwind error
> properly.

See the implementation of otx2_tc_alloc_ent_bitmap() as following:

int otx2_tc_alloc_ent_bitmap(struct otx2_nic *nic)
{
	struct otx2_tc_info *tc = &nic->tc_info;

	if (!nic->flow_cfg->max_flows)
		return 0;

	/* Max flows changed, free the existing bitmap */
	kfree(tc->tc_entries_bitmap);
	
	...
}

Hello Leon Romanovsky,

It will kfree(tc->tc_entries_bitmap) firstly, and otx2_tc_alloc_ent_bitmap()
is called by otx2_dl_mcam_count_set() and otx2_init_tc(). I am not sure their
sequence and whether it will cause double free for tc->tc_entries_bitmap. So
setting tc->tc_entries_bitmap to NULL is safe, I think.

Thank you!

> 
>> +	}
>> +	return err;
>>  }
>>  EXPORT_SYMBOL(otx2_init_tc);
>>  
>> -- 
>> 2.25.1
>>
> .
>