[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 21 May 2012 08:38:31 +0200
From: Marcus Meissner <meissner@...e.de>
To: OSS Security List <oss-security@...ts.openwall.com>
Subject: CVE Request: some drm overflow checks
Hi,
spotted in xorls blog, who spotted it in the kernel stable changelog:
https://xorl.wordpress.com/2012/05/17/linux-kernel-drm-intel-i915-multiple-ioctl-integer-overflows/
It has two issues:
1. overflow of cliprect kmalloc as args->num_cliprects is not bounded
and passed in via a user ioctl.
Fixed via ed8cd3b2cd61004cab85380c52b1817aca1ca49b in mainline:
commit ed8cd3b2cd61004cab85380c52b1817aca1ca49b
Author: Xi Wang <xi.wang@...il.com>
Date: Mon Apr 23 04:06:41 2012 -0400
drm/i915: fix integer overflow in i915_gem_execbuffer2()
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").
8408c282 was added Feb 21 2011, and seemingly added during 2.6.38 development.
2. same file, overflow in args->buffer_count.
Fix is in mainline 44afb3a04391a74309d16180d1e4f8386fdfa745
commit 44afb3a04391a74309d16180d1e4f8386fdfa745
Author: Xi Wang <xi.wang@...il.com>
Date: Mon Apr 23 04:06:42 2012 -0400
drm/i915: fix integer overflow in i915_gem_do_execbuffer()
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").
432e58ed was added during 2.6.37 development.
I think it needs 2 CVEs, due to the different kernel versions introducing it.
Ciao, Marcus
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Powered by Openwall GNU/*/Linux -
Powered by OpenVZ