Re: Null dereference errors in the kernel

["Dmitry Torokhov" <dmitry.torokhov@gmail.com>]

On 7/18/06, Daniel Drake <dsd@gentoo.org> wrote:
> Thomas Dillig wrote:
> > Hello,
> >
> > We are PhD students at Stanford University working on a static analysis
> > project called SATURN (http://glide.stanford.edu/saturn). We have
> > implemented a checker that finds potential null dereference errors and
> > ran our tool on the kernel version 2.6.17.1. We have identified around
> > 300 potential issues related to null errors, and we've included 20
> > sample reports below. If you would be interested, we can post all the
> > issues we found. Also, we apologize in advance if we aren't supposed to
> > post these error reports here, and we are happy to submit bug reports
> > elsewhere if you tell us where to post these.
>
> Interesting idea. I just looked at one of them out of curiosity, but I'm
> not sure it is valid. Either that or I have misunderstood the problem it
> is identifying?
>
> > [13]
> > 1176, 1180 drivers/char/isicom.c
> > Possible null dereference of variable "tty" checked for NULL at
> > (1183:drivers/char/isicom.c).
>
> This function is part of the tty_operations API, that would be a pretty
> broken interface if it provided the possibility of a NULL tty to work
> on. Additionally, all of the callers seem to do this:
>
>        tty->driver->put_char(tty, c);
>
> If tty is NULL here, we have larger problems at hand :)
>

That if (!tty...) check is bogus. The tool is apparently unhappy
because the code does:

struct isi_port *port = tty->driver_data;
....
if (!tty || !port->xmit_buf)
        return;

It looks like the problem is gone in the latest -git. The same issue
is in isicom_close() WRT port argument.

-- 
Dmitry