All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: linux1394-devel@lists.sourceforge.net
Cc: linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Ramos <daramos@stanford.edu>
Subject: Re: [PATCH] drivers/firewire: fix use/leak of uninitialized stack memory in dispatch_ioctl()
Date: Tue, 11 Nov 2014 17:13:56 +0100	[thread overview]
Message-ID: <20141111171356.2fc62440@kant> (raw)
In-Reply-To: <20141111130143.2ff3d42e@kant>

Adding Cc: linux-api and lkml, quoting parent message in full

On Nov 11 Stefan Richter wrote:
> On Nov 11 Stefan Richter wrote:
> > On Nov 10 David Ramos wrote:
> > > This patch fixes an uninitialized memory use/leak bug discovered
> > > by our UC-KLEE tool in the 3.16.3 kernel.
> > 
> > There is uninitialized memory use, but no leak.
> 
> Actually there could be leaks too.  If later fw_cdev_event_ are
> generated, they will contain the __u64 closure field that many of the
> ioctl argument structures contain.
> 
> > [...]
> > > If a user carefully crafts an ioctl command such that _IOC_DIR(cmd)
> > > == 0, 'buffer' is left uninitialized. Each of the ioctl_handlers then
> > > accesses the pre-existing stack values, which will cause unpredictable
> > > behavior.
> > 
> > Not all (but indeed almost all) ioctl handlers will use uninitialized
> > memory in that case.  The damage should be marginal though, because all of
> > these handlers must implement sufficient arguments checking anyway.
> > 
> > > This patch checks for an invalid cmd and rejects it with -ENOTTY.
> > 
> > This is not exactly what your patch does.  Rather...
> > 
> > > --- a/drivers/firewire/core-cdev.c
> > > +++ b/drivers/firewire/core-cdev.c
> > > @@ -1632,7 +1632,8 @@ static int dispatch_ioctl(struct client *client,
> > >  	if (fw_device_is_shutdown(client->device))
> > >  		return -ENODEV;
> > >  
> > > -	if (_IOC_TYPE(cmd) != '#' ||
> > > +	if (_IOC_DIR(cmd) == _IOC_NONE ||
> > > +	    _IOC_TYPE(cmd) != '#' ||
> > >  	    _IOC_NR(cmd) >= ARRAY_SIZE(ioctl_handlers) ||
> > >  	    _IOC_SIZE(cmd) > sizeof(buffer))
> > >  		return -ENOTTY;
> > 
> > ...it quits *all* _IOC_NONE ioctls with -ENOTTY, not just invalid ones.
> > If you have a look at the ABI definition in
> > include/uapi/linux/firewire-cdev.h, you will notice that this approach is
> > insufficient.
> 
> I suppose we should add checks
>   1. for _IOC_DIR matching the expected direction depending on _IOC_NR
>      (or at least for presence of _IOC_WRITE when expected), and
>   2. for _IOC_SIZE being at least as big as the minimum unaligned argument
>      size depending on _IOC_NR (at least in case of
>      _IOC_DIR(cmd) & _IOC_WRITE).
> 
> BTW, I don't think it is worthwhile to check for upper bounds of _IOC_SIZE
> besides the present check against sizeof(buffer), since the precise size of
> arguments depends on structure alignment of the user code and on ABI
> version.

I will follow up with two alternative patches for discussion; either one
should fix the issue but they differ in complexity and runtime cost:
    [PATCH RFC v1a] firewire: cdev: prevent kernel stack leaking into ioctl arguments
    [PATCH RFC v1b] firewire: cdev: prevent kernel stack leaking into ioctl arguments
If I receive no feedback to the contrary, I will probably submit patch v1b
to upstream, which is the simpler one of the two.
-- 
Stefan Richter
-=====-====- =-== -=-==
http://arcgraph.de/sr/

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk

WARNING: multiple messages have this Message-ID (diff)
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: linux1394-devel@lists.sourceforge.net
Cc: David Ramos <daramos@stanford.edu>,
	linux-api@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers/firewire: fix use/leak of uninitialized stack memory in dispatch_ioctl()
Date: Tue, 11 Nov 2014 17:13:56 +0100	[thread overview]
Message-ID: <20141111171356.2fc62440@kant> (raw)
In-Reply-To: <20141111130143.2ff3d42e@kant>

Adding Cc: linux-api and lkml, quoting parent message in full

On Nov 11 Stefan Richter wrote:
> On Nov 11 Stefan Richter wrote:
> > On Nov 10 David Ramos wrote:
> > > This patch fixes an uninitialized memory use/leak bug discovered
> > > by our UC-KLEE tool in the 3.16.3 kernel.
> > 
> > There is uninitialized memory use, but no leak.
> 
> Actually there could be leaks too.  If later fw_cdev_event_ are
> generated, they will contain the __u64 closure field that many of the
> ioctl argument structures contain.
> 
> > [...]
> > > If a user carefully crafts an ioctl command such that _IOC_DIR(cmd)
> > > == 0, 'buffer' is left uninitialized. Each of the ioctl_handlers then
> > > accesses the pre-existing stack values, which will cause unpredictable
> > > behavior.
> > 
> > Not all (but indeed almost all) ioctl handlers will use uninitialized
> > memory in that case.  The damage should be marginal though, because all of
> > these handlers must implement sufficient arguments checking anyway.
> > 
> > > This patch checks for an invalid cmd and rejects it with -ENOTTY.
> > 
> > This is not exactly what your patch does.  Rather...
> > 
> > > --- a/drivers/firewire/core-cdev.c
> > > +++ b/drivers/firewire/core-cdev.c
> > > @@ -1632,7 +1632,8 @@ static int dispatch_ioctl(struct client *client,
> > >  	if (fw_device_is_shutdown(client->device))
> > >  		return -ENODEV;
> > >  
> > > -	if (_IOC_TYPE(cmd) != '#' ||
> > > +	if (_IOC_DIR(cmd) == _IOC_NONE ||
> > > +	    _IOC_TYPE(cmd) != '#' ||
> > >  	    _IOC_NR(cmd) >= ARRAY_SIZE(ioctl_handlers) ||
> > >  	    _IOC_SIZE(cmd) > sizeof(buffer))
> > >  		return -ENOTTY;
> > 
> > ...it quits *all* _IOC_NONE ioctls with -ENOTTY, not just invalid ones.
> > If you have a look at the ABI definition in
> > include/uapi/linux/firewire-cdev.h, you will notice that this approach is
> > insufficient.
> 
> I suppose we should add checks
>   1. for _IOC_DIR matching the expected direction depending on _IOC_NR
>      (or at least for presence of _IOC_WRITE when expected), and
>   2. for _IOC_SIZE being at least as big as the minimum unaligned argument
>      size depending on _IOC_NR (at least in case of
>      _IOC_DIR(cmd) & _IOC_WRITE).
> 
> BTW, I don't think it is worthwhile to check for upper bounds of _IOC_SIZE
> besides the present check against sizeof(buffer), since the precise size of
> arguments depends on structure alignment of the user code and on ABI
> version.

I will follow up with two alternative patches for discussion; either one
should fix the issue but they differ in complexity and runtime cost:
    [PATCH RFC v1a] firewire: cdev: prevent kernel stack leaking into ioctl arguments
    [PATCH RFC v1b] firewire: cdev: prevent kernel stack leaking into ioctl arguments
If I receive no feedback to the contrary, I will probably submit patch v1b
to upstream, which is the simpler one of the two.
-- 
Stefan Richter
-=====-====- =-== -=-==
http://arcgraph.de/sr/

       reply	other threads:[~2014-11-11 16:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <55D28623-C1C7-47D2-9638-0B8FD0733C48@stanford.edu>
     [not found] ` <20141111010340.3329bbd7@kant>
     [not found]   ` <20141111130143.2ff3d42e@kant>
2014-11-11 16:13     ` Stefan Richter [this message]
2014-11-11 16:13       ` [PATCH] drivers/firewire: fix use/leak of uninitialized stack memory in dispatch_ioctl() Stefan Richter
2014-11-11 16:15       ` [PATCH RFC v1a] firewire: cdev: prevent kernel stack leaking into ioctl arguments Stefan Richter
2014-11-11 16:15         ` Stefan Richter
2014-11-11 16:16       ` [PATCH RFC v1b] " Stefan Richter
2014-11-11 16:16         ` Stefan Richter
2014-11-11 18:22         ` Clemens Ladisch
2014-11-11 18:22           ` Clemens Ladisch

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=20141111171356.2fc62440@kant \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=daramos@stanford.edu \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    /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.