[PATCH] drm/mm: avoid possible null pointer dereference

Chris Wilson chris at chris-wilson.co.uk
Mon May 23 13:46:59 UTC 2016


On Mon, May 23, 2016 at 02:38:29PM +0100, Eric Engestrom wrote:
> On Mon, May 23, 2016 at 02:02:26PM +0100, Chris Wilson wrote:
> > On Mon, May 23, 2016 at 02:56:45PM +0200, Daniel Vetter wrote:
> > > On Mon, May 23, 2016 at 11:27:14AM +0100, Eric Engestrom wrote:
> > > > On Wed, May 18, 2016 at 10:17:19PM +0200, Heinrich Schuchardt wrote:
> > > > > Do not dereference node before the check if node is NULL.
> > > > > 
> > > > > Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
> > > > > ---
> > > > >  drivers/gpu/drm/drm_mm.c | 4 +++-
> > > > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> > > > > index 04de6fd..cb39f45 100644
> > > > > --- a/drivers/gpu/drm/drm_mm.c
> > > > > +++ b/drivers/gpu/drm/drm_mm.c
> > > > > @@ -179,12 +179,14 @@ static void drm_mm_insert_helper(struct drm_mm_node *hole_node,
> > > > >  int drm_mm_reserve_node(struct drm_mm *mm, struct drm_mm_node *node)
> > > > >  {
> > > > >  	struct drm_mm_node *hole;
> > > > > -	u64 end = node->start + node->size;
> > > > > +	u64 end;
> > > > >  	u64 hole_start;
> > > > >  	u64 hole_end;
> > > > >  
> > > > >  	BUG_ON(node == NULL);
> > > > >  
> > > > > +	end = node->start + node->size;
> > > > > +
> > > > >  	/* Find the relevant hole to add our node to */
> > > > >  	drm_mm_for_each_hole(hole, mm, hole_start, hole_end) {
> > > > >  		if (hole_start > node->start || hole_end < end)
> > > > > -- 
> > > > > 2.1.4
> > > > 
> > > > Reviewed-by: Eric Engestrom <eric.engestrom at imgtec.com>
> > 
> > Remove useless check instead?
> > -Chris
> 
> I tend to prefer erring on the side of caution and have (too) many checks,
> especially simple ones like avoiding null dereferences.

BUG(node == NULL) is no more informative than hitting a GFP with *node.

> That said, BUG() might be too extreme. I'm not all that familiar with
> the code, but it doesn't seem like it would be an unrecoverable failure.
> WARN() instead?

It's a programming error, just as would be passing in mm == NULL. Mark up
the function as requiring non-NULL parameters.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the dri-devel mailing list