All of lore.kernel.org
 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

WARNING: multiple messages have this Message-ID (diff)
From: julia.lawall@lip6.fr (Julia Lawall)
To: cocci@systeme.lip6.fr
Subject: [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 at 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: 9+ 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-14 13:28   ` [Cocci] " Nicholas Mc Guire
2015-12-18  6:33   ` Julia Lawall [this message]
2015-12-18  6:33     ` Julia Lawall
     [not found]     ` <alpine.DEB.2.02.1512180727310.2052-bi+AKbBUZKagILUCTcTcHdKyNwTtLsGr@public.gmane.org>
2015-12-18 14:20       ` Nicholas Mc Guire
2015-12-18 14:20         ` Nicholas Mc Guire
2015-12-20 12:59         ` Julia Lawall
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.