From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752036AbbFALJt (ORCPT <rfc822;w@1wt.eu>);
	Mon, 1 Jun 2015 07:09:49 -0400
Received: from mail-la0-f49.google.com ([209.85.215.49]:36159 "EHLO
	mail-la0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751253AbbFALJi (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 1 Jun 2015 07:09:38 -0400
Message-ID: <556C3D69.1030909@cogentembedded.com>
Date: Mon, 01 Jun 2015 14:09:29 +0300
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Colin Ian King <colin.king@canonical.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
        Felipe Balbi <balbi@ti.com>, Sudeep Holla <sudeep.holla@arm.com>,
        linux-usb@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: isp1760: fix null dereference if kzalloc returns
 null
References: <1433109649-4086-1-git-send-email-colin.king@canonical.com> <556B87FC.5080908@cogentembedded.com> <556B8E0D.8020703@canonical.com>
In-Reply-To: <556B8E0D.8020703@canonical.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hello.

On 6/1/2015 1:41 AM, Colin Ian King wrote:

>>> From: Colin Ian King <colin.king@canonical.com>

>>> If kzalloc returns null then isp1760_ep_alloc_request performs
>>> a null pointer deference on req.

>>     Dereference, not "deference".

> Shall I send v2 for this stupid typo then?

    Definitely, especially as your change log doesn't adequately reflect 
reality anyway.

>>     No, it doesn't. It calculates the address of the
>> 'isp1760_request::req' instead, there's no dereference per se. I suppose
>> this is a first member of the structure, so this function should work
>> correctly in any case.

> Well, for now it's the first member, but can we assume that will apply
> forever?

    I guess so.

> As it stands, other *_alloc_request() functions in all the
> other usb drivers check for the NULL, so this fix just aligns the code
> with all of these other drivers.

    OK.

[...]

WBR, Sergei