From: Dave Jones <davej@redhat.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>,
Ben Widawsky <ben@bwidawsk.net>,
Tommi Rantala <tt.rantala@gmail.com>,
David Airlie <airlied@linux.ie>,
intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer
Date: Sun, 17 Mar 2013 17:58:58 -0400 [thread overview]
Message-ID: <20130317215858.GD3703@redhat.com> (raw)
In-Reply-To: <CAKMK7uFiMLcE_TYj5=sKZsVAcCnWSmg49qPrxjswH2s3J5byOg@mail.gmail.com>
On Sun, Mar 17, 2013 at 08:50:03PM +0100, Daniel Vetter wrote:
> Doesn't that mean that we need these checks everywhere? Or at least a
> fixup in drm core proper?
>
> And I think we need to add trinity to our test setup eventually ;-)
Note that trinity's ioctl fuzzing is still very new (added in just
the last few weeks), and for drm isn't very advanced at all yet.
I was pretty surprised when Tommi's changes started turning up bugs
so quickly, but I guess a lot of the ioctl paths have just never been
audited for these kinds of bugs.
As you can see at
https://github.com/kernelslacker/trinity/blob/master/ioctls/drm.c
It's literally just enumerating the known ioctl's, and using the
generic fuzzing routines (so it just guesses what the argument is,
and hence passes crap like NULL, or a page of garbage).
Eventually I'd like to have routines for each of the individual ioctl
cases to pass something that looks slightly more realistic to what
it's expecting to see.
(Compare to say, the SCSI SG_IO routines here:
https://github.com/kernelslacker/trinity/blob/master/ioctls/scsi.c
[still kinda dumb, but gives an idea of the direction])
Lots of work ahead.
Dave
prev parent reply other threads:[~2013-03-17 21:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-14 12:41 i915 drm oopses while fuzzing Tommi Rantala
2013-03-14 12:59 ` [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer Chris Wilson
2013-03-14 13:39 ` Tommi Rantala
2013-03-15 4:43 ` [Intel-gfx] " Ben Widawsky
2013-03-15 4:50 ` Ben Widawsky
2013-03-15 8:24 ` Chris Wilson
2013-03-15 16:36 ` Ben Widawsky
2013-03-15 22:06 ` Chris Wilson
2013-03-15 23:49 ` Ben Widawsky
2013-03-16 10:19 ` Chris Wilson
2013-03-17 19:50 ` Daniel Vetter
2013-03-17 21:40 ` Chris Wilson
2013-03-17 21:42 ` Dave Airlie
2013-03-17 21:51 ` Chris Wilson
2013-04-11 18:59 ` Tommi Rantala
2013-03-17 21:58 ` Dave Jones [this message]
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=20130317215858.GD3703@redhat.com \
--to=davej@redhat.com \
--cc=airlied@linux.ie \
--cc=ben@bwidawsk.net \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tt.rantala@gmail.com \
/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