linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Shaobo" <shaobo@cs.utah.edu>
To: linux-fbdev@vger.kernel.org
Subject: RE: Potential NULL pointer dereference in drivers/video/fbdev/sis/init.c
Date: Sat, 18 Feb 2017 22:29:47 +0000	[thread overview]
Message-ID: <002f01d28a36$838193a0$8a84bae0$@cs.utah.edu> (raw)
In-Reply-To: <22ff6151c00b3abef040afcd601c6b76@cs.utah.edu>

Hi Manuel,

Thanks a lot for your reply.

I just realized that the NULL pointer dereference condition may be weaker than the one in the previous email. It turns out as long as ModeNo <= 0x13, then `queuedata` will not get updated to a non-null value and eventually get dereferenced either at line 2523 or line 2529 if the execution does not break before. If this analysis makes sense, then there may be multiple dead code locations in this file given there is no NULL pointer dereference.

Shaobo
-----Original Message-----
From: Manuel Schölling [mailto:manuel.schoelling@gmx.de] 
Sent: 2017年2月18日 2:47
To: Shaobo <shaobo@cs.utah.edu>; linux-fbdev@vger.kernel.org
Cc: thomas@winischhofer.net; b.zolnierkie@samsung.com
Subject: Re: Potential NULL pointer dereference in drivers/video/fbdev/sis/init.c

Hi Shaobo,

On Sat, 2017-02-18 at 00:26 -0700, Shaobo wrote:
> I am applying a static analysis tool to the Linux device drivers and 
> got an error trace of null pointer dereference in 
> drivers/video/fbdev/sis/init.c starting from function
> SiS_SetCRT1FIFO_630: pointer `queuedata` is initialized to NULL at 
> line
> 2409 and could get dereferenced at line 2501 if ModeNo <= 0x13 and 
> SiS_Pr->ChipType = SIS_730. To be more specific, if ModeNo <= 0x13 
> then the locations (line 2449 or line 2451)where `queuedata` gets 
> updated to a non null value is skipped. And if `SiS_Pr->ChipType = 
> SIS_730`, then `queuedata` is dereferenced. As you can see, the error 
> trace is only plausible since it depends on certain conditions. 
> Therefore, I was wondering if you could confirm it.
Thanks for your analysis! I agree with your static code analysis and there is a potential NULL dereference.

Please note that I am not really familiar with the details of this driver, so I am not sure what the code SHOULD look like and if this potential dereference can really occur at runtime.

Maybe somebody else with a little bit more insight into the details of this driver might want to comment on this?

Bye,

Manuel


      parent reply	other threads:[~2017-02-18 22:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-18  7:26 Potential NULL pointer dereference in drivers/video/fbdev/sis/init.c Shaobo
2017-02-18  9:47 ` Manuel Schölling
2017-02-18 22:29 ` Shaobo [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='002f01d28a36$838193a0$8a84bae0$@cs.utah.edu' \
    --to=shaobo@cs.utah.edu \
    --cc=linux-fbdev@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).