On Fri, 6 Apr 2012 10:01:36 -0400, Xi Wang <xi.wang@xxxxxxxxx> wrote: > On Apr 6, 2012, at 9:54 AM, Chris Wilson wrote: > > > On Fri, 6 Apr 2012 09:46:46 -0400, Xi Wang <xi.wang@xxxxxxxxx> wrote: > >> On Apr 6, 2012, at 9:36 AM, Chris Wilson wrote: > >> > >>> On Fri, 6 Apr 2012 08:58:18 -0400, Xi Wang <xi.wang@xxxxxxxxx> wrote: > >>>> A large args->buffer_count from userspace may overflow the allocation > >>>> size, leading to out-of-bounds access. > >>>> > >>>> Use kmalloc_array() to avoid that. > >>> > >>> I can safely say that exec list larger than 4GiB is going to be an > >>> illegal operation and would rather the ioctl failed outright with > >>> EINVAL. > >> > >> On 32-bit platform? > > > > On any platform. The largest it can legally be is a few tens of megabytes. > > IDGI. First we come to i915_gem_execbuffer2() from ioctl: > > exec2_list = kmalloc(sizeof(*exec2_list)*args->buffer_count, ...); > > args->buffer_count is passed from userspace so it can be any value. That I agreed with, I just disagree with how you chose to handle it. Rather than continue on and attempt to vmalloc a large array we should just fail the ioctl with EINVAL. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
