linux-kernel - Re: [PATCH] usb: usbip: fix 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:	Mon, 06 Jun 2016 10:20:37 +0200
From:	Krzysztof Opasiak <k.opasiak@...sung.com>
To:	Sudip Mukherjee <sudipm.mukherjee@...il.com>,
	Valentina Manea <valentina.manea.m@...il.com>,
	Shuah Khan <shuah.kh@...sung.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH] usb: usbip: fix null pointer dereference



On 06/05/2016 07:54 PM, Sudip Mukherjee wrote:
> On Friday 03 June 2016 09:29 AM, Krzysztof Opasiak wrote:
>>
>>
>> On 06/02/2016 03:22 PM, Sudip Mukherjee wrote:
>>> We have been dereferencing udc before checking it. Lets use it after it
>>> has been checked.
>>>
>>
>> To be honest I have mixed feelings about this patch.
>>
>> On one hand it prevents us from dereferencing potential NULL ptr what is
>> generally good. But on the other hand it seems to be a little bit
>> pointless overhead. This function is called only in one place, it's
>> internal function of vudc driver and in addition generally it is
>> currently impossible that this function will get NULL ptr as parameter
>> as it's value is taken from container_of(). Not to mention that if this
>> is NULL or garbage we will end up in NULL ptr dereference much earlier
>> before calling this function.
>>
>> So if there is something that you would like to fix with this patch and
>> you have a real problem with this function could you please provide us
>> some more details (for example stack trace)? If this patch is just to
>> prevent us from something that will never happen then I would rather to
>> not submit this. In my opinion if we get a NULL in this function this
>> means that we have some serious problem in UDC core and this check will
>> just mask this error.
> 
> Yes, I should have seen earlier that the only caller has already
> dereferenced udc. So maybe the following will be appropriate in this
> situation.
>

Your patch does exactly what Alan suggested and I agree with it;)

Could you please resend this properly so Greg can easily pick it up?

Best regards,
-- 
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics