drm/i915: Prevent overflow of execbuf.buffer_count and num_cliprects
authorChris Wilson <chris@chris-wilson.co.uk>
Thu, 16 Nov 2017 10:50:59 +0000 (10:50 +0000)
committerChris Wilson <chris@chris-wilson.co.uk>
Thu, 16 Nov 2017 14:17:08 +0000 (14:17 +0000)
commitd710fc16ff0749f7a8bd33c69785513fe8b95fb8
treea9971ed439ef3fad80ef2ef4a92f53de086b9fb4
parentc534612e780c4a2c8ef5bfc11583c7d58436baca
drm/i915: Prevent overflow of execbuf.buffer_count and num_cliprects

We check whether the multiplies will overflow prior to calling
kmalloc_array so that we can respond with -EINVAL for the invalid user
arguments rather than treating it as an -ENOMEM that would otherwise
occur. However, as Dan Carpenter pointed out, we did an addition on the
unsigned int prior to passing to kmalloc_array where it would be
promoted to size_t for the calculation, thereby allowing it to overflow
and underallocate.

v2: buffer_count is currently limited to INT_MAX because we treat it as
signaled variable for LUT_HANDLE in eb_lookup_vma
v3: Move common checks for eb1/eb2 into the same function
v4: Put the check back for nfence*sizeof(user_fence) overflow
v5: access_ok uses ULONG_MAX but kvmalloc_array uses SIZE_MAX
v6: size_t and unsigned long are not type-equivalent on 32b

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171116105059.25142-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
drivers/gpu/drm/i915/i915_gem_execbuffer.c