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
next parent reply other threads:[~2014-11-11 16:13 UTC|newest]
Thread overview: 4+ 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:15 ` [PATCH RFC v1a] firewire: cdev: prevent kernel stack leaking into ioctl arguments Stefan Richter
2014-11-11 16:16 ` [PATCH RFC v1b] " Stefan Richter
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).