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] [day] [month] [year] [list]
Message-ID: <DC148C5AA1CEBA4E87973D432B1C2D8825FE61A0@P3PWEX4MB008.ex4.secureserver.net>
Date:	Tue, 14 Oct 2014 16:53:37 +0000
From:	Hartley Sweeten <HartleyS@...ionengravers.com>
To:	Ian Abbott <abbotti@....co.uk>,
	"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 Thursday, October 09, 2014 2:03 AM, Ian Abbott wrote:
> 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.

Ah. OK.

Reviewed-by: H Hartley Sweeten <hsweeten@...ionengravers.com>

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ