On Mon, 22 Nov 2010 12:56:42 +0300, Dan Carpenter <error27@xxxxxxxxx> wrote:
> On Sun, Nov 21, 2010 at 09:23:46AM +0000, Chris Wilson wrote:
> > Yes, it could. Not through normal use since relocation count can not be
> > more than buffer length, hence realistically capped at around 4k entries.
> > However...
> >
>
> If the user deliberately made it wrap to get past the access_ok() check
> then it would just return -ENOENT in i915_gem_execbuffer_relocate()
> right?
>
> It doesn't look like there are any security implications but I just
> wanted to be sure.
I think it did have a security implication, because it would only validate
the first x bytes of the user pointer but then continue to read/write
beyond. It would have to be a fairly crafty user! I've queued a fix in
the drm-intel-fixes branch:
commit d1d788302e8c76e5138dfa61f4a5eee4f72a748f
Author: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Date: Sun Nov 21 09:23:48 2010 +0000
drm/i915: Prevent integer overflow when validating the execbuffer
Commit 2549d6c2 removed the vmalloc used for temporary storage of the
relocation lists used during execbuffer. However, our use of vmalloc was
being protected by an integer overflow check which we do want to
preserve!
Reported-by: Dan Carpenter <error27@xxxxxxxxx>
Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Many thanks,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
