On 32-bit systems, a large args->num_cliprects from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.
This vulnerability was introduced in commit 432e58ed ("drm/i915: Avoid
allocation for execbuffer object list").
Signed-off-by: Xi Wang
Cc: Chr
On 32-bit systems, a large args->buffer_count from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.
This vulnerability was introduced in commit 8408c282 ("drm/i915:
First try a normal large kmalloc for the temporary exec buffers").
Signed-off-by
On 32-bit systems, a large args-buffer_count from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.
This vulnerability was introduced in commit 8408c282 (drm/i915:
First try a normal large kmalloc for the temporary exec buffers).
Signed-off-by: Xi Wang xi.w
On 32-bit systems, a large args-num_cliprects from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.
This vulnerability was introduced in commit 432e58ed (drm/i915: Avoid
allocation for execbuffer object list).
Signed-off-by: Xi Wang xi.w...@gmail.com
Cc
Since cmdbuf->size and cmdbuf->nbox are from userspace, a large value
would overflow the allocation size, leading to out-of-bounds access.
Signed-off-by: Xi Wang
---
drivers/gpu/drm/savage/savage_state.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drive
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
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()
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 userspac
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.
>
A large args->num_cliprects from userspace may overflow the allocation
size, leading to out-of-bounds access.
| i915_gem_do_execbuffer()
| i915_gem_execbuffer()
Use kmalloc_array() to avoid that.
Signed-off-by: Xi Wang
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |4 ++--
1 fi
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 --
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 xi.w...@gmail.com
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions
A large args-num_cliprects from userspace may overflow the allocation
size, leading to out-of-bounds access.
| i915_gem_do_execbuffer()
| i915_gem_execbuffer()
Use kmalloc_array() to avoid that.
Signed-off-by: Xi Wang xi.w...@gmail.com
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |4
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()
will
On Apr 6, 2012, at 3:40 PM, Chris Wilson wrote:
On Fri, 6 Apr 2012 14:17:41 -0400, Xi Wang xi.w...@gmail.com 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
Since cmdbuf-size and cmdbuf-nbox are from userspace, a large value
would overflow the allocation size, leading to out-of-bounds access.
Signed-off-by: Xi Wang xi.w...@gmail.com
---
drivers/gpu/drm/savage/savage_state.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git
_cmd->pitch * (u64)mode_cmd->height;
This patch calls the existing vmw_kms_validate_mode_vram() for
validation.
Signed-off-by: Xi Wang
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
On Dec 21, 2011, at 4:30 AM, David Airlie wrote:
>
> This patch doesn't apply with git am, please regenerate it,
>
> Thomas, can you ack as well please?
>
> Is this for -fixes or -next?
Sorry this patch is for vmwgfx.git. I will redo a version that can be applied
to the mainline kernel.
-
= (u64)mode_cmd-pitch * (u64)mode_cmd-height;
This patch calls an existing function vmw_kms_validate_mode_vram()
for validation.
Signed-off-by: Xi Wang xi.w...@gmail.com
---
vmwgfx_kms.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/vmwgfx_kms.c b/vmwgfx_kms.c
index
On Dec 21, 2011, at 4:30 AM, David Airlie wrote:
This patch doesn't apply with git am, please regenerate it,
Thomas, can you ack as well please?
Is this for -fixes or -next?
Sorry this patch is for vmwgfx.git. I will redo a version that can be applied
to the mainline kernel.
- xi
-height;
This patch calls the existing vmw_kms_validate_mode_vram() for
validation.
Signed-off-by: Xi Wang xi.w...@gmail.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm
the multiplication.
required_size = (u64)mode_cmd->pitch * (u64)mode_cmd->height;
This patch calls an existing function vmw_kms_validate_mode_vram()
for validation.
Signed-off-by: Xi Wang
---
vmwgfx_kms.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/vmwgfx_kms.c b/vm
;
This fix calls vmw_kms_validate_mode_vram() for validation.
Signed-off-by: Xi Wang xi.w...@gmail.com
Cc: Thomas Hellstrom thellst...@vmware.com
Cc: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git
pitch * (u64)mode_cmd->height;
This fix calls vmw_kms_validate_mode_vram() for validation.
Signed-off-by: Xi Wang
Cc: Thomas Hellstrom
Cc: Dave Airlie
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmw
Hi,
I came across this code snippet at vmwgfx_kms.c:2000. The loop variable i is
never used and rects is checked again and again. Should it be something like
rects[i].x instead of rects->x? Thanks.
for (i = 0; i < arg->num_outputs; ++i) {
if (rects->x < 0 ||
Hi,
I came across this code snippet at vmwgfx_kms.c:2000. The loop variable i is
never used and rects is checked again and again. Should it be something like
rects[i].x instead of rects-x? Thanks.
for (i = 0; i arg-num_outputs; ++i) {
if (rects-x 0 ||
There is a potential integer overflow in drm_mode_dirtyfb_ioctl()
if userspace passes in a large num_clips. The call to kmalloc would
allocate a small buffer, and the call to fb->funcs->dirty may result
in a memory corruption.
Reported-by: Haogang Chen
Signed-off-by: Xi Wang
---
drive
There is a potential integer overflow in drm_mode_dirtyfb_ioctl()
if userspace passes in a large num_clips. The call to kmalloc would
allocate a small buffer, and the call to fb-funcs-dirty may result
in a memory corruption.
Reported-by: Haogang Chen haogangc...@gmail.com
Signed-off-by: Xi Wang
28 matches
Mail list logo
