All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: linux-staging@lists.linux.dev, Viresh Kumar <vireshk@kernel.org>,
	Johan Hovold <johan@kernel.org>, Alex Elder <elder@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: drivers/staging/greybus/bootrom.c: fw is NULL but dereferenced
Date: Fri, 28 May 2021 10:03:52 +0200	[thread overview]
Message-ID: <1931377.TGo55UGoA0@linux.local> (raw)
In-Reply-To: <20210528033301.soqgwfwfy4ls6a2a@vireshk-i7>

On Friday, May 28, 2021 5:33:01 AM CEST Viresh Kumar wrote:
> On 28-05-21, 01:39, Fabio M. De Francesco wrote:
> > Coccinelle detected that fw is NULL but dereferenced.
> > 
> > static int gb_bootrom_get_firmware(struct gb_operation *op)
> > {
> > /* lines of code */
> > 
> >         if (!fw) {
> >         
> >                 dev_err(dev, "%s: firmware not available\n", __func__);
> >                 ret = -EINVAL;
> 
> ret is set here.
>
Oh sorry. I entirely skipped that "ret = -EINVAL". Another case where one 
should avoid blindly trusting the output of static analyzers without looking 
carefully at the whole context ... :(

Unfortunately, Coccinelle has a high false positive rate. Just yesterday I ran 
it against the entire driver / staging and more than 80% of the warnings / 
errors weren't true.

It takes so long to distinguish the fake from the real that I wonder if it's 
worth it to run the (slow) Coccinelle, wait for the output messages and verify 
their veracity.

Thanks,

Fabio
> 
> >                 goto unlock;
> >         
> >         }
> > 
> > /* lines of code */
> > 
> > unlock:
> >         unlock:
> >         mutex_unlock(&bootrom->mutex);
> > 
> > queue_work:
> >         /* Refresh timeout */
> >         if (!ret && (offset + size == fw->size))    <--- here
> 
> Since we are checking for !ret here, we will never access fw and this is a 
bug
> in the tool and not the code here.
> 
> > 	next_request = NEXT_REQ_READY_TO_BOOT;
> > 
> > /* lines of code */
> > }
> > 
> > I really don't know if the following change may break something else:
> >         if(!ret && fw && (offset + size == fw->size))
> > 	
> > 	next_request = NEXT_REQ_READY_TO_BOOT;
> > 
> > So, I'll leave the problem to the maintainers or to other people who know 
how
> > the driver is supposed to manage fw == NULL.
> > 
> > Thanks,
> > 
> > Fabio




  reply	other threads:[~2021-05-28  8:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-27 23:39 drivers/staging/greybus/bootrom.c: fw is NULL but dereferenced Fabio M. De Francesco
2021-05-28  3:33 ` Viresh Kumar
2021-05-28  8:03   ` Fabio M. De Francesco [this message]
2021-05-28 10:42     ` Dan Carpenter
2021-05-28 10:29 ` Dan Carpenter

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=1931377.TGo55UGoA0@linux.local \
    --to=fmdefrancesco@gmail.com \
    --cc=elder@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=johan@kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=viresh.kumar@linaro.org \
    --cc=vireshk@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.