On Fri, 6 Apr 2012 14:17:41 -0400, Xi Wang wrote:
> On Apr 6, 2012, at 10:44 AM, Chris Wilson wrote:
>
> > 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.
>
> Why
On Apr 6, 2012, at 3:40 PM, Chris Wilson wrote:
> On Fri, 6 Apr 2012 14:17:41 -0400, Xi Wang wrote:
>>
>> Why an attempt to vmalloc? The overflow check in drm_malloc_ab()
>> will simply return NULL and fail the ioctl with -ENOMEM.
>
> It's an invalid value for the ioctl and should be treated as
On Fri, 6 Apr 2012 10:01:36 -0400, Xi Wang wrote:
> On Apr 6, 2012, at 9:54 AM, Chris Wilson wrote:
>
> > On Fri, 6 Apr 2012 09:46:46 -0400, Xi Wang wrote:
> >> On Apr 6, 2012, at 9:36 AM, Chris Wilson wrote:
> >>
> >>> On Fri, 6 Apr 2012 08:58:18 -0400, Xi Wang wrote:
> A large args->bu
On Fri, 6 Apr 2012 09:46:46 -0400, Xi Wang wrote:
> On Apr 6, 2012, at 9:36 AM, Chris Wilson wrote:
>
> > On Fri, 6 Apr 2012 08:58:18 -0400, Xi Wang wrote:
> >> A large args->buffer_count from userspace may overflow the allocation
> >> size, leading to out-of-bounds access.
> >>
> >> Use kmall
On Fri, 6 Apr 2012 08:58:18 -0400, Xi Wang 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 woul
On Apr 6, 2012, at 10:44 AM, Chris Wilson wrote:
> 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.
Why an attempt to vmalloc? The overflow check in drm_malloc_ab()
wil
On Apr 6, 2012, at 3:40 PM, Chris Wilson wrote:
> On Fri, 6 Apr 2012 14:17:41 -0400, Xi Wang wrote:
>>
>> Why an attempt to vmalloc? The overflow check in drm_malloc_ab()
>> will simply return NULL and fail the ioctl with -ENOMEM.
>
> It's an invalid value for the ioctl and should be treated as
On Fri, 6 Apr 2012 14:17:41 -0400, Xi Wang wrote:
> On Apr 6, 2012, at 10:44 AM, Chris Wilson wrote:
>
> > 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.
>
> Why
On Apr 6, 2012, at 10:44 AM, Chris Wilson wrote:
> 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.
Why an attempt to vmalloc? The overflow check in drm_malloc_ab()
wil
On Apr 6, 2012, at 9:54 AM, Chris Wilson wrote:
> On Fri, 6 Apr 2012 09:46:46 -0400, Xi Wang wrote:
>> On Apr 6, 2012, at 9:36 AM, Chris Wilson wrote:
>>
>>> On Fri, 6 Apr 2012 08:58:18 -0400, Xi Wang wrote:
A large args->buffer_count from userspace may overflow the allocation
size,
On Apr 6, 2012, at 9:36 AM, Chris Wilson wrote:
> On Fri, 6 Apr 2012 08:58:18 -0400, Xi Wang 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 la
A large args->buffer_count from userspace may overflow the allocation
size, leading to out-of-bounds access.
Use kmalloc_array() to avoid that.
Signed-off-by: Xi Wang
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drive
On Fri, 6 Apr 2012 10:01:36 -0400, Xi Wang wrote:
> On Apr 6, 2012, at 9:54 AM, Chris Wilson wrote:
>
> > On Fri, 6 Apr 2012 09:46:46 -0400, Xi Wang wrote:
> >> On Apr 6, 2012, at 9:36 AM, Chris Wilson wrote:
> >>
> >>> On Fri, 6 Apr 2012 08:58:18 -0400, Xi Wang wrote:
> A large args->bu
On Apr 6, 2012, at 9:54 AM, Chris Wilson wrote:
> On Fri, 6 Apr 2012 09:46:46 -0400, Xi Wang wrote:
>> On Apr 6, 2012, at 9:36 AM, Chris Wilson wrote:
>>
>>> On Fri, 6 Apr 2012 08:58:18 -0400, Xi Wang wrote:
A large args->buffer_count from userspace may overflow the allocation
size,
On Fri, 6 Apr 2012 09:46:46 -0400, Xi Wang wrote:
> On Apr 6, 2012, at 9:36 AM, Chris Wilson wrote:
>
> > On Fri, 6 Apr 2012 08:58:18 -0400, Xi Wang wrote:
> >> A large args->buffer_count from userspace may overflow the allocation
> >> size, leading to out-of-bounds access.
> >>
> >> Use kmall
On Apr 6, 2012, at 9:36 AM, Chris Wilson wrote:
> On Fri, 6 Apr 2012 08:58:18 -0400, Xi Wang 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 la
On Fri, 6 Apr 2012 08:58:18 -0400, Xi Wang 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 woul
A large args->buffer_count from userspace may overflow the allocation
size, leading to out-of-bounds access.
Use kmalloc_array() to avoid that.
Signed-off-by: Xi Wang
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drive
18 matches
Mail list logo