Quoting Tvrtko Ursulin (2017-11-16 14:00:50) > > On 16/11/2017 10:50, Chris Wilson wrote: > > 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@xxxxxxxxxx> > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> ... > Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> Ta. Certainly makes type-safe languages appealing. Pushed, -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
