linux-kernel - Re: Null dereference errors in the kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d120d5000607180545v2fa45d6nab6a5132f18a1306@mail.gmail.com>
Date:	Tue, 18 Jul 2006 08:45:07 -0400
From:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
To:	"Daniel Drake" <dsd@...too.org>
Cc:	"Thomas Dillig" <tdillig@...nford.edu>,
	linux-kernel@...r.kernel.org
Subject: Re: Null dereference errors in the kernel

On 7/18/06, Daniel Drake <dsd@...too.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/