linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Thompson <daniel.thompson@linaro.org>
To: FUZZ DR <driverfuzzing@gmail.com>
Cc: Lee Jones <lee.jones@linaro.org>,
	Jingoo Han <jingoohan1@gmail.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] backlight: pcf50633: pdata may be a null pointer, null pointer dereference cause crash
Date: Wed, 3 Feb 2021 11:42:28 +0000	[thread overview]
Message-ID: <20210203114228.4tr4j6hxukayo4ei@maple.lan> (raw)
In-Reply-To: <CABF6pWFar726YKG9y_wVZoX9fd7DxBQce0AZKAibmmzU9qZpMA@mail.gmail.com>

On Tue, Feb 02, 2021 at 03:25:49PM -0600, FUZZ DR wrote:
> Sorry about the missing description, I have a description at my local
> commit. But the commit description disappeared when I used git send-email
> to submit this patch.
> 
> backlight: pcf50633: pdata may be a null pointer, null pointer dereference
> causes crash
> pdata has been checked  at line 120 before dereference. However, it is used
> without check at line 130. So just add the check,

To be clear what your analyzer is reporting is a mismatch of programmer
intent.

In line 120 suggests a belief that pdata could be NULL whilst line 130
suggests a belief that pdata is never NULL. Your analyzer cannot not tell
you which belief is incorrect, only that there is a mismatch.


> It is better to write a default value to the register if the ramp_time has
> a default value. Then it does not need to return -EINVAL. It will keep
> consistent with the behavior at line 120.

I disagree.

You have assumed that line 120 is correct and that this code needs to
support the case where pdata is NULL. However eleven years of history
disprove this! This code is never called without valid platform data.

Therefore we should fix the assumption on line 120 by making it clear
that this code code expects non-NULL platform data. Given there are
developers working to eliminate this kind of platform data structure
(by adopting device properties instead) I don't want to make their
life harder by implementing unused and untested special cases that
they would have to reason about.


Daniel.


> 
> Daniel Thompson <daniel.thompson@linaro.org> 于2021年2月2日周二 上午3:25写道:
> 
> > On Mon, Feb 01, 2021 at 08:41:38AM -0600, Wenjia Zhao wrote:
> > > Signed-off-by: Wenjia Zhao <driverfuzzing@gmail.com>
> >
> > There should be a patch description here explaining why the patch
> > is needed and how it works.
> >
> >
> > > ---
> > >  drivers/video/backlight/pcf50633-backlight.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/video/backlight/pcf50633-backlight.c
> > b/drivers/video/backlight/pcf50633-backlight.c
> > > index 540dd338..43267af 100644
> > > --- a/drivers/video/backlight/pcf50633-backlight.c
> > > +++ b/drivers/video/backlight/pcf50633-backlight.c
> > > @@ -127,7 +127,8 @@ static int pcf50633_bl_probe(struct platform_device
> > *pdev)
> > >
> > >       platform_set_drvdata(pdev, pcf_bl);
> > >
> > > -     pcf50633_reg_write(pcf_bl->pcf, PCF50633_REG_LEDDIM,
> > pdata->ramp_time);
> > > +  if (pdata)
> > > +    pcf50633_reg_write(pcf_bl->pcf, PCF50633_REG_LEDDIM,
> > pdata->ramp_time);
> >
> > Assuming you found this issue using a static analyzer then I think it
> > might be better to if an "if (!pdata) return -EINVAL" further up the
> > file instead.
> >
> > In other words it is better to "document" (via the return code) that the
> > code does not support pdata == NULL than to add another untested code
> > path.
> >
> >
> > Daniel.
> >

      parent reply	other threads:[~2021-02-03 11:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-01 14:41 [PATCH] backlight: pcf50633: pdata may be a null pointer, null pointer dereference cause crash Wenjia Zhao
2021-02-02  8:28 ` Lee Jones
2021-02-02  9:25 ` Daniel Thompson
     [not found]   ` <CABF6pWFar726YKG9y_wVZoX9fd7DxBQce0AZKAibmmzU9qZpMA@mail.gmail.com>
2021-02-03 11:42     ` Daniel Thompson [this message]

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=20210203114228.4tr4j6hxukayo4ei@maple.lan \
    --to=daniel.thompson@linaro.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=driverfuzzing@gmail.com \
    --cc=jingoohan1@gmail.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@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;
as well as URLs for NNTP newsgroup(s).