linux-kernel - Re: [PATCH] usb: u132-hcd: fix potential NULL pointer dereference

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]

Date:   Tue, 19 Mar 2019 12:20:05 -0500
From:   Kangjie Lu <kjlu@....edu>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     pakki001@....edu, Colin Ian King <colin.king@...onical.com>,
        Jia-Ju Bai <baijiaju1990@...il.com>, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: u132-hcd: fix potential NULL pointer dereference


On 3/19/19 8:56 AM, Greg Kroah-Hartman wrote:
> On Thu, Mar 14, 2019 at 02:27:11AM -0500, Kangjie Lu wrote:
>> In case create_singlethread_workqueue fails, the fix notifies
>> callers the error to avoid potential NULL pointer dereferences.
>>
>> Signed-off-by: Kangjie Lu <kjlu@....edu>
>> ---
>>   drivers/usb/host/u132-hcd.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c
>> index 934584f0a20a..6d5b532b03f8 100644
>> --- a/drivers/usb/host/u132-hcd.c
>> +++ b/drivers/usb/host/u132-hcd.c
>> @@ -3203,6 +3203,8 @@ static int __init u132_hcd_init(void)
>>   		return -ENODEV;
>>   	printk(KERN_INFO "driver %s\n", hcd_name);
>>   	workqueue = create_singlethread_workqueue("u132");
>> +	if (unlikely(!workqueue))
> You only ever use unlikely/likely if you can actually measure the
> difference with and without it.  For stuff like this, it is not needed
> at all, and in fact, the compiler and CPU already know this type of
> thing, so it is going to be faster without it.
>
> And are you sure you properly unwound from anything that was
> created/initialized above these lines?
I didn't see what resources require release in this
case.
Given the existing error paths for usb_disabled() and
platform_driver_register(), returning -ENOMEM looks
like a consistent error handling. Let me know if it
isn't.


>
> thanks,
>
> greg k-h