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: <56a08bd2-6b94-457f-99f7-91ef3fca8804@arm.com>
Date:   Tue, 11 Jun 2019 10:54:15 +0100
From:   Marc Zyngier <marc.zyngier@....com>
To:     Gen Zhang <blackgod016574@...il.com>, ssantosh@...nel.org,
        olof@...om.net
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] knav_qmss_queue: fix a missing-check bug in
 knav_pool_create()

Hi Gen,

No idea why I'm being cc'd on this but hey... ;-)

On 11/06/2019 10:37, Gen Zhang wrote:
> On Thu, May 30, 2019 at 11:39:49AM +0800, Gen Zhang wrote:
>> In knav_pool_create(), 'pool->name' is allocated by kstrndup(). It
>> returns NULL when fails. So 'pool->name' should be checked. And free
>> 'pool' when error.
>>
>> Signed-off-by: Gen Zhang <blackgod016574@...il.com>
>> ---
>> diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
>> index 8b41837..0f8cb28 100644
>> --- a/drivers/soc/ti/knav_qmss_queue.c
>> +++ b/drivers/soc/ti/knav_qmss_queue.c
>> @@ -814,6 +814,12 @@ void *knav_pool_create(const char *name,
>>  	}
>>  
>>  	pool->name = kstrndup(name, KNAV_NAME_SIZE - 1, GFP_KERNEL);
>> +	if (!pool->name) {
>> +		dev_err(kdev->dev, "failed to duplicate for pool(%s)\n",
>> +			name);

There is no need to output anything, the kernel will be loud enough if
you run out of memory.

>> +		ret = -ENOMEM;
>> +		goto err_name;
>> +	}
>>  	pool->kdev = kdev;
>>  	pool->dev = kdev->dev;
>>  
>> @@ -864,6 +870,7 @@ void *knav_pool_create(const char *name,
>>  	mutex_unlock(&knav_dev_lock);
>>  err:
>>  	kfree(pool->name);
>> +err_name:

kfree(NULL) is perfectly valid, there is no need to create a second
label. Just branch to the existing error label.

>>  	devm_kfree(kdev->dev, pool);
>>  	return ERR_PTR(ret);
>>  }
> Can anyone look into this patch?
> 
> Thanks
> Gen
> 

The real question is whether this is actually an error at all.
pool->name doesn't seem to be used for anything but debug information,
and the printing code can perfectly accommodate a NULL pointer.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ