Received-SPF: pass (google.com: domain of linux-kernel+bounces-189059-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Sat, 25 May 2024 03:46:12 +0800
From: Kuan-Wei Chiu <visitorckw@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: jserv@ccns.ncku.edu.tw, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tools/lib/slab: Fix potential NULL pointer dereference
 in kmalloc()
Message-ID: <ZlDuhAPHNw5ZCfjH@visitorckw-System-Product-Name>
References: <20240524191459.949731-1-visitorckw@gmail.com>
 <20240524122350.a22ca8dfe07a21f3eb862159@linux-foundation.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240524122350.a22ca8dfe07a21f3eb862159@linux-foundation.org>

On Fri, May 24, 2024 at 12:23:50PM -0700, Andrew Morton wrote:
> On Sat, 25 May 2024 03:14:59 +0800 Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> 
> > In kmalloc(), add a check to ensure that the pointer 'ret' is not NULL
> > before attempting to memset it when the __GFP_ZERO flag is set. This
> > prevents a potential NULL pointer dereference.
> > 
> > ...
> >
> > --- a/tools/lib/slab.c
> > +++ b/tools/lib/slab.c
> > @@ -22,7 +22,7 @@ void *kmalloc(size_t size, gfp_t gfp)
> >  	uatomic_inc(&kmalloc_nr_allocated);
> >  	if (kmalloc_verbose)
> >  		printf("Allocating %p from malloc\n", ret);
> > -	if (gfp & __GFP_ZERO)
> > +	if (gfp & __GFP_ZERO && ret)
> >  		memset(ret, 0, size);
> >  	return ret;
> >  }
> 
> I suspect we have a lot of unchecked mallocs in our userspace code.  If
> there's an argument for fixing them all(?) then it would be best to do
> this in a wholesale fashion rather than patch-at-a-time piecemeal.
>
It seems likely that I'm not the first to notice the unchecked mallocs
in our userspace code if they're indeed widespread. Are there specific
reasons or guidelines indicating when malloc checks are necessary, and
when they can be omitted?

Regards,
Kuan-Wei