All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <error27@gmail.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: bug report: potential integer overflow in validate_exec_list()
Date: Mon, 22 Nov 2010 12:56:42 +0300	[thread overview]
Message-ID: <20101122095642.GD1522@bicker> (raw)
In-Reply-To: <849307$af353c@azsmga001.ch.intel.com>

On Sun, Nov 21, 2010 at 09:23:46AM +0000, Chris Wilson wrote:
> On Sat, 20 Nov 2010 21:32:07 +0300, Dan Carpenter <error27@gmail.com> wrote:
> > Hello Chris,
> > 
> > Is there an integer overflow in validate_exec_list()?
> > 
> > drivers/gpu/drm/i915/i915_gem.c
> >   3633          size_t length = exec[i].relocation_count * sizeof(struct drm_i915_gem_relocation_entry);
> >   3634  
> >   3635          if (!access_ok(VERIFY_READ, ptr, length))
> >   3636                  return -EFAULT;
> >   3637  
> > 
> > My concern is that if relocation_count is larger than 0x8000000 the
> > multiplication can wrap.
> 
> 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.

regards,
dan carpenter

  reply	other threads:[~2010-11-22  9:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-20 18:32 bug report: potential integer overflow in validate_exec_list() Dan Carpenter
2010-11-21  9:23 ` Chris Wilson
2010-11-22  9:56   ` Dan Carpenter [this message]
2010-11-22 10:35     ` Chris Wilson

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=20101122095642.GD1522@bicker \
    --to=error27@gmail.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.