All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Abbott <abbotti@mev.co.uk>
To: Hartley Sweeten <HartleyS@visionengravers.com>,
	"driverdev-devel@linuxdriverproject.org" 
	<driverdev-devel@linuxdriverproject.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Bernd Porr <mail@berndporr.me.uk>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] staging: comedi: (regression) channel list must be set for COMEDI_CMD ioctl
Date: Thu, 09 Oct 2014 10:02:55 +0100	[thread overview]
Message-ID: <54364F3F.4060201@mev.co.uk> (raw)
In-Reply-To: <DC148C5AA1CEBA4E87973D432B1C2D8825FDD84E@P3PWEX4MB008.ex4.secureserver.net>

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@berndporr.me.uk>
>> Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
>> Cc: Bernd Porr <mail@berndporr.me.uk>
>> Cc: <stable@vger.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@mev.co.uk> )=-
-=(                          Web: http://www.mev.co.uk/  )=-

  reply	other threads:[~2014-10-09  9:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-08 15:09 [PATCH] staging: comedi: (regression) channel list must be set for COMEDI_CMD ioctl Ian Abbott
2014-10-08 23:13 ` Hartley Sweeten
2014-10-09  9:02   ` Ian Abbott [this message]
2014-10-14 16:53     ` Hartley Sweeten

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54364F3F.4060201@mev.co.uk \
    --to=abbotti@mev.co.uk \
    --cc=HartleyS@visionengravers.com \
    --cc=driverdev-devel@linuxdriverproject.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mail@berndporr.me.uk \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.