From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751874AbcFERyl (ORCPT ); Sun, 5 Jun 2016 13:54:41 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:33115 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751556AbcFERyj (ORCPT ); Sun, 5 Jun 2016 13:54:39 -0400 Message-ID: <5754675B.1050104@gmail.com> Date: Sun, 05 Jun 2016 18:54:35 +0100 From: Sudip Mukherjee User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Krzysztof Opasiak , Valentina Manea , Shuah Khan , Greg Kroah-Hartman CC: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCH] usb: usbip: fix null pointer dereference References: <1464873753-11456-1-git-send-email-sudipm.mukherjee@gmail.com> <57513FF3.6050608@samsung.com> In-Reply-To: <57513FF3.6050608@samsung.com> Content-Type: multipart/mixed; boundary="------------030407020305060408000204" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is a multi-part message in MIME format. --------------030407020305060408000204 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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. Regards Sudip --------------030407020305060408000204 Content-Type: text/plain; charset=UTF-8; name="patch1" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch1" diff --git a/drivers/usb/usbip/vudc_sysfs.c b/drivers/usb/usbip/vudc_sysfs.c index 99397fa..0f98f2c 100644 --- a/drivers/usb/usbip/vudc_sysfs.c +++ b/drivers/usb/usbip/vudc_sysfs.c @@ -40,7 +40,7 @@ int get_gadget_descs(struct vudc *udc) struct usb_ctrlrequest req; int ret; - if (!udc || !udc->driver || !udc->pullup) + if (!udc->driver || !udc->pullup) return -EINVAL; req.bRequestType = USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEVICE; --------------030407020305060408000204--