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
next prev parent 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.