Linux-Next discussions
 help / color / mirror / Atom feed
From: Julia Lawall <julia.lawall@lip6.fr>
To: Nicholas Mc Guire <der.herr@hofr.at>
Cc: devel@driverdev.osuosl.org, linux-rdma@vger.kernel.org,
	dledford@redhat.com, linux-next@vger.kernel.org,
	Cocci@systeme.lip6.fr
Subject: Re: [Cocci] [PATCH] staging/rdma/hfi1: Fix a possible null pointer dereference
Date: Fri, 18 Dec 2015 07:33:36 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.02.1512180727310.2052@localhost6.localdomain6> (raw)
In-Reply-To: <20151214132849.GA22053@osadl.at>



On Mon, 14 Dec 2015, Nicholas Mc Guire wrote:

> On Thu, Dec 10, 2015 at 11:13:38AM -0500, Mike Marciniszyn wrote:
> > From: Easwar Hariharan <easwar.hariharan@intel.com>
> > 
> > A code inspection pointed out that kmalloc_array may return NULL and
> > memset doesn't check the input pointer for NULL, resulting in a possible
> > NULL dereference. This patch fixes this.
> > 
> > Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
> > Signed-off-by: Easwar Hariharan <easwar.hariharan@intel.com>
> > ---
> >  drivers/staging/rdma/hfi1/chip.c |    2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/staging/rdma/hfi1/chip.c b/drivers/staging/rdma/hfi1/chip.c
> > index dc69159..49d49b2 100644
> > --- a/drivers/staging/rdma/hfi1/chip.c
> > +++ b/drivers/staging/rdma/hfi1/chip.c
> > @@ -10129,6 +10129,8 @@ static void init_qos(struct hfi1_devdata *dd, u32 first_ctxt)
> >  	if (num_vls * qpns_per_vl > dd->chip_rcv_contexts)
> >  		goto bail;
> >  	rsmmap = kmalloc_array(NUM_MAP_REGS, sizeof(u64), GFP_KERNEL);
> > +	if (!rsmmap)
> > +		goto bail;
> >  	memset(rsmmap, rxcontext, NUM_MAP_REGS * sizeof(u64));
> >  	/* init the local copy of the table */
> >  	for (i = 0, ctxt = first_ctxt; i < num_vls; i++) {
> > 
> > --
> 
> Based on this report a generalization of unchecked use turned up one more
> case in the current kernel (patch sent). Probably the  when  block needs 
> some cleanup, but findings like this definitely are a case for coccinelle 
> scanners.
> 
> <snip>
> /// check for missing NULL check before use                                     
> //
> //  missing check in: 
> //  ./drivers/staging/rdma/hfi1/chip.c:10131 unchecked allocation
> //  in -next-20151214
> //  reported-by Mike Marciniszyn <mike.marciniszyn@intel.com> 
> //
> //  after generalization this also found:
> //  ./drivers/clk/shmobile/clk-div6.c:197 unchecked allocation
> 
> virtual context
> virtual org
> virtual report
> 
> @badmemset@
> expression mem;
> position p;
> statement S;
> @@
> 
> <+...
> *mem = kmalloc_array@p(...);
>   ... when != if (!mem || ...) S
>       when != if (... && !mem) S
>       when != if (mem == NULL || ...) S
>       when != if (... && mem == NULL) S
>       when != if (unlikely(mem == NULL)) S
>       when != if (unlikely(!mem)) S
>       when != if (likely(!mem)) S
>       when != if (likely(mem == NULL)) S
>   return;
> ...+>
> 
> @script:python@
> p << badmemset.p;
> @@
> 
> print "%s:%s unchecked allocation" % (p[0].file,p[0].line)
> 
> <snip>

How about the following?  I got two hits with this, in 
drivers/clk/shmobile/clk-div6.c and drivers/staging/rdma/hfi1/chip.c.

@@
expression mem;
identifier f;
@@

*mem = kmalloc_array(...);
... when != mem == NULL
    when != mem != NULL
(
f(...,mem,...)
|
mem->f
|
mem[...]
)

There is a semantic patch in the kernel called kmerr that goes in this 
direction, but it seems to be overly restrictive and it doesn't address 
this function:

/// This semantic patch looks for kmalloc etc that are not followed by a
/// NULL check.  It only gives a report in the case where there is some
/// error handling code later in the function, which may be helpful
/// in determining what the error handling code for the call to kmalloc etc
/// should be.

Probably there are a lot of other functions that should be considered.

julia

  reply	other threads:[~2015-12-18  6:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-10 16:13 [PATCH] staging/rdma/hfi1: Fix a possible null pointer dereference Mike Marciniszyn
2015-12-14 13:28 ` Nicholas Mc Guire
2015-12-18  6:33   ` Julia Lawall [this message]
     [not found]     ` <alpine.DEB.2.02.1512180727310.2052-bi+AKbBUZKagILUCTcTcHdKyNwTtLsGr@public.gmane.org>
2015-12-18 14:20       ` [Cocci] " Nicholas Mc Guire
2015-12-20 12:59         ` Julia Lawall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.02.1512180727310.2052@localhost6.localdomain6 \
    --to=julia.lawall@lip6.fr \
    --cc=Cocci@systeme.lip6.fr \
    --cc=der.herr@hofr.at \
    --cc=devel@driverdev.osuosl.org \
    --cc=dledford@redhat.com \
    --cc=linux-next@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox