[Intel-gfx] [PATCH] drm/i915/gem: Detect overflow in calculating dumb buffer size

[Ville Syrjälä]

On Thu, Jan 23, 2020 at 01:39:03PM +0000, Chris Wilson wrote:
> Quoting Ville Syrjälä (2020-01-23 13:27:07)
> > On Thu, Jan 23, 2020 at 12:59:34PM +0000, Chris Wilson wrote:
> > > To multiply 2 u32 numbers to generate a u64 in C requires a bit of
> > > forewarning for the compiler.
> > > 
> > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > Cc: Ramalingam C <ramalingam.c at intel.com>
> > > Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> > > Cc: stable at vger.kernel.org
> > > ---
> > >  drivers/gpu/drm/i915/i915_gem.c | 5 ++++-
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > > index 0a20083321a3..ff79da5657f8 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -265,7 +265,10 @@ i915_gem_dumb_create(struct drm_file *file,
> > >                                                   DRM_FORMAT_MOD_LINEAR))
> > >               args->pitch = ALIGN(args->pitch, 4096);
> > >  
> > > -     args->size = args->pitch * args->height;
> > > +     if (args->pitch < args->width)
> > > +             return -EINVAL;
> > > +
> > > +     args->size = mul_u32_u32(args->pitch, args->height);
> > 
> > I thought something would have checked these against the mode_config
> > fb limits already. But can't see code like that anywhere. Maybe we
> > should just do that in the core?
> 
> While it is in uapi/drm_mode.h, is there any restriction that the dumb
> buffer has to be used with a framebuffer? Not that I have a good use
> case, just wondering if we need to be so proscriptive.

I think the general concensus has been that anything else is an abuse
of the interface (not that it has stopped people from doing it IIRC).

But maybe there's some good use for it that I can't think up.

Reviewed-by: Ville Syrjälä <ville.syrjala at linux.intel.com>

> 
> We create something that is compatible but presume we will need later
> validation against HW.
> -Chris

-- 
Ville Syrjälä
Intel