linux-kernel - Re: [PATCH] staging: comedi: (regression) channel list must be set for COMEDI

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:	Thu, 09 Oct 2014 10:02:55 +0100
From:	Ian Abbott <abbotti@....co.uk>
To:	Hartley Sweeten <HartleyS@...ionengravers.com>,
	"driverdev-devel@...uxdriverproject.org" 
	<driverdev-devel@...uxdriverproject.org>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Bernd Porr <mail@...ndporr.me.uk>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH] staging: comedi: (regression) channel list must be set
 for COMEDI_CMD ioctl

On 09/10/14 00:13, Hartley Sweeten wrote:
> On Wednesday, October 08, 2014 8:09 AM, Ian Abbott wrote:
>> `do_cmd_ioctl()`, the handler for the `COMEDI_CMD` ioctl can incorrectly
>> call the Comedi subdevice's `do_cmd()` handler with a NULL channel list
>> pointer.  This is a regression as the `do_cmd()` handler has never been
>> expected to deal with that, leading to a kernel OOPS when it tries to
>> dereference it.
>>
>> A NULL channel list pointer is allowed for the `COMEDI_CMDTEST` ioctl,
>> handled by `do_cmdtest_ioctl()` and the subdevice's `do_cmdtest()`
>> handler, but not for the `COMEDI_CMD` ioctl and its handlers.
>>
>> Both `do_cmd_ioctl()` and `do_cmdtest_ioctl()` call
>> `__comedi_get_user_chanlist()` to copy the channel list from user memory
>> into dynamically allocated kernel memory and check it for consistency.
>> That function currently returns 0 if the `user_chanlist` parameter
>> (pointing to the channel list in user memory) is NULL.  That's fine for
>> `do_cmdtest_ioctl()`, but `do_cmd_ioctl()` incorrectly assumes the
>> kernel copy of the channel list has been set-up correctly.
>>
>> Fix it by not allowing the `user_chanlist` parameter to be NULL in
>> `__comedi_get_user_chanlist()`, and only calling it from
>> `do_cmdtest_ioctl()` if the parameter is non-NULL.
>>
>> Thanks to Bernd Porr for reporting the bug via an initial patch sent
>> privately.
>>
>> Fixes: c6cd0eefb27b ("staging: comedi: comedi_fops: introduce __comedi_get_user_chanlist()")
>> Reported-by: Bernd Porr <mail@...ndporr.me.uk>
>> Signed-off-by: Ian Abbott <abbotti@....co.uk>
>> Cc: Bernd Porr <mail@...ndporr.me.uk>
>> Cc: <stable@...r.kernel.org> # 3.15.y 3.16.y 3.17.y
>> ---
>>   drivers/staging/comedi/comedi_fops.c | 15 +++++++--------
>>   1 file changed, 7 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/staging/comedi/comedi_fops.c b/drivers/staging/comedi/comedi_fops.c
>> index 495969f..a9b7fe5 100644
>> --- a/drivers/staging/comedi/comedi_fops.c
>> +++ b/drivers/staging/comedi/comedi_fops.c
>> @@ -1462,10 +1462,6 @@ static int __comedi_get_user_chanlist(struct comedi_device *dev,
>>   	unsigned int *chanlist;
>>   	int ret;
>>
>> -	/* user_chanlist could be NULL for do_cmdtest ioctls */
>> -	if (!user_chanlist)
>> -		return 0;
>> -
>
> I think you need a check here to avoid a NULL pointer getting
> passed to the  memdup_user().
>
> 	If (!user_chanlist || cmd->chanlist_len == 0)
> 		return -EINVAL;
>
>>   	chanlist = memdup_user(user_chanlist,
>>   			       cmd->chanlist_len * sizeof(unsigned int));
>>   	if (IS_ERR(chanlist))

It's fine to pass a NULL pointer to memdup_user().  It won't succeed 
(returning ERR_PTR(-EFAULT)), but it's fine.

-- 
-=( Ian Abbott @ MEV Ltd.    E-mail: <abbotti@....co.uk> )=-
-=(                          Web: http://www.mev.co.uk/  )=-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/