Null dereference errors in the kernel

Null dereference errors in the kernel

[Thomas Dillig]

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.

Thanks,
Thomas & Isil Dillig



Error reports:


[1]
790 drivers/video/modedb.c
NULL dereference of variable "best"


[2]
6538 drivers/scsi/aic7xxx/aic7xxx_core.c
Possible null dereference of variable "cur_column" checked for NULL at 
(6531:drivers/scsi/aic7xxx/aic7xxx_core.c)


[3]
46 sound/isa/sb/sb8_midi.c
NULL dereference of variable "chip" (inside macro SBP() )


[4]
239 drivers/usb/misc/usblcd.c
NULL dereference of variable "urb".


[5]
916 drivers/char/specialix.c
Possible null dereference of "bp" checked for NULL at 
(917:drivers/char/specialix.c). Dereferenced through call chain 
(drivers/char/specialix.c:sx_get_port, drivers/char/specialix.c:sx_in)


[6]
1196, 1201, 1204,... drivers/net/irda/donauboe.c
Possible null dereference of variable "self" checked for NULL at 
(1170:drivers/net/irda/donauboe.c)


[7]
144 drivers/char/agp/ati-agp.c
NULL dereference of variable "ati_generic_private.gatt_pages" in 
function call (drivers/char/agp/ati-agp.c:ati_free_gatt_pages).


[8]
816 net/decnet/dn_route.c
Possible null dereference of variable "rt->u.dst.dev" checked for NULL 
at (809:net/decnet/dn_route.c) and aliased as variable "dev".


[9]
100 drivers/mtd/maps/ts5500_flash.c
NULL dereference of variable of "mymtd" in function call (map_destroy).


[10]
1092, 1093, 1115 drivers/net/bonding/bond_sysfs.c
Possible null dereference of variable "slave" checked for NULL at 
(1097:drivers/net/bonding/bond_sysfs.c), aliased as variable "new_active".


[11]
512, 513 fs/ntfs/attrib.c
Possible null dereference of variable "ctx" checked for NULL at 
(474:fs/ntfs/attrib.c).


[12]
562, 563 drivers/ide/pci/pdc202xx_old.c
Possible null dereference of variable "hwif" checked for NULL at 
(565:drivers/ide/pci/pdc202xx_old.c).


[13]
1176, 1180 drivers/char/isicom.c
Possible null dereference of variable "tty" checked for NULL at 
(1183:drivers/char/isicom.c).


[14]
1230, 1232 drivers/scsi/tmscsim.c
Possible null dereference of variable "psgl" checked for NULL at 
(1249:drivers/scsi/tmscsim.c), aliased as "pcmd->request_buffer".


[15]
680 drivers/net/3c505.c
Possible null dereference  of variable "adapter->current_dma.skb" in 
function call (include/linux/netdevice.h:dev_kfree_skb_irq) checked at 
(688:drivers/net/3c505.c), aliased as variable "skb".


[16]
965 drivers/net/tulip/dmfe.c
NULL dereference of variable "skb".


[17]
730 drivers/net/hamradio/6pack.c
Possible null dereference of variable "sp" checked for NULL at 
(733:drivers/net/hamradio/6pack.c).


[18]
405 drivers/acpi/dispatcher/dswload.c
Possible null dereference of variable "op->common.value.arg" checked for 
NULL at (418:drivers/acpi/dispatcher/dswload.c).

[19]
639 fs/cifs/readdir.c
Possible null dereference of variable 
"cifsFile->srch_inf.ntwrk_buf_start" in function call (smbCalcSize), 
checked for NULL at (610:fs/cifs/readdir.c).


[20]
197, 198 fs/ocfs2/aops.c
Possible null dereference of variable "page" checked for NULL at 
(201:fs/ocfs2/aops.c).

Re: Null dereference errors in the kernel

[Joshua Henderson]

Looked at the first 4.  These are valid errors.  Seems like a rather 
intelligent tool.  When will this tool be publicly available?

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.
>
> Thanks,
> Thomas & Isil Dillig
>
>
>
> Error reports:
>
>
> [1]
> 790 drivers/video/modedb.c
> NULL dereference of variable "best"
There in 2.6.17.1.  Fixed in at least 2.6.18-rc1.
>
>
> [2]
> 6538 drivers/scsi/aic7xxx/aic7xxx_core.c
> Possible null dereference of variable "cur_column" checked for NULL at 
> (6531:drivers/scsi/aic7xxx/aic7xxx_core.c)
Looks possible in 2.6.18-rc1.
>
>
> [3]
> 46 sound/isa/sb/sb8_midi.c
> NULL dereference of variable "chip" (inside macro SBP() )
There in 2.6.17.1.  Fixed in at least 2.6.18-rc1.
>
>
> [4]
> 239 drivers/usb/misc/usblcd.c
> NULL dereference of variable "urb".
Definitely in 2.6.18-rc1.
>
>
> [5]
> 916 drivers/char/specialix.c
> Possible null dereference of "bp" checked for NULL at 
> (917:drivers/char/specialix.c). Dereferenced through call chain 
> (drivers/char/specialix.c:sx_get_port, drivers/char/specialix.c:sx_in)
>
>
> [6]
> 1196, 1201, 1204,... drivers/net/irda/donauboe.c
> Possible null dereference of variable "self" checked for NULL at 
> (1170:drivers/net/irda/donauboe.c)
>
>
> [7]
> 144 drivers/char/agp/ati-agp.c
> NULL dereference of variable "ati_generic_private.gatt_pages" in 
> function call (drivers/char/agp/ati-agp.c:ati_free_gatt_pages).
>
>
> [8]
> 816 net/decnet/dn_route.c
> Possible null dereference of variable "rt->u.dst.dev" checked for NULL 
> at (809:net/decnet/dn_route.c) and aliased as variable "dev".
>
>
> [9]
> 100 drivers/mtd/maps/ts5500_flash.c
> NULL dereference of variable of "mymtd" in function call (map_destroy).
>
>
> [10]
> 1092, 1093, 1115 drivers/net/bonding/bond_sysfs.c
> Possible null dereference of variable "slave" checked for NULL at 
> (1097:drivers/net/bonding/bond_sysfs.c), aliased as variable 
> "new_active".
>
>
> [11]
> 512, 513 fs/ntfs/attrib.c
> Possible null dereference of variable "ctx" checked for NULL at 
> (474:fs/ntfs/attrib.c).
>
>
> [12]
> 562, 563 drivers/ide/pci/pdc202xx_old.c
> Possible null dereference of variable "hwif" checked for NULL at 
> (565:drivers/ide/pci/pdc202xx_old.c).
>
>
> [13]
> 1176, 1180 drivers/char/isicom.c
> Possible null dereference of variable "tty" checked for NULL at 
> (1183:drivers/char/isicom.c).
>
>
> [14]
> 1230, 1232 drivers/scsi/tmscsim.c
> Possible null dereference of variable "psgl" checked for NULL at 
> (1249:drivers/scsi/tmscsim.c), aliased as "pcmd->request_buffer".
>
>
> [15]
> 680 drivers/net/3c505.c
> Possible null dereference  of variable "adapter->current_dma.skb" in 
> function call (include/linux/netdevice.h:dev_kfree_skb_irq) checked at 
> (688:drivers/net/3c505.c), aliased as variable "skb".
>
>
> [16]
> 965 drivers/net/tulip/dmfe.c
> NULL dereference of variable "skb".
>
>
> [17]
> 730 drivers/net/hamradio/6pack.c
> Possible null dereference of variable "sp" checked for NULL at 
> (733:drivers/net/hamradio/6pack.c).
>
>
> [18]
> 405 drivers/acpi/dispatcher/dswload.c
> Possible null dereference of variable "op->common.value.arg" checked 
> for NULL at (418:drivers/acpi/dispatcher/dswload.c).
>
> [19]
> 639 fs/cifs/readdir.c
> Possible null dereference of variable 
> "cifsFile->srch_inf.ntwrk_buf_start" in function call (smbCalcSize), 
> checked for NULL at (610:fs/cifs/readdir.c).
>
>
> [20]
> 197, 198 fs/ocfs2/aops.c
> Possible null dereference of variable "page" checked for NULL at 
> (201:fs/ocfs2/aops.c).
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Null dereference errors in the kernel

[Thomas Dillig]

Joshua Henderson wrote:
> Looked at the first 4.  These are valid errors.  Seems like a rather 
> intelligent tool.  When will this tool be publicly available?

We are currently aiming for a public release of the SATURN tool some 
time in fall this year. Other students are also working on different 
types of analyses/verification modules, which will slowly become ready 
if everything goes as planned.



Eugene Teo wrote:
> I would be interested. Can you email bug reports so that bugs can be 
> fixed?
> Also, please email security@kernel.org so that they can verify the reports
> should there be any false negatives.
Also, we will ready (e.g. double-check and pretty-print) more reports 
and mail them (CC'ed to security@kernel.org) in chunks as soon as they 
are ready. Please let us know if there is anything else you want us to do.

Thanks a lot, it's exciting to hear back from developers after working 
on this for a long time :)
-Isil & Tom

Re: Null dereference errors in the kernel

[Daniel Drake]

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 :)

I'm also unsure how this null dereference is related to line 1183.

Daniel

Re: Null dereference errors in the kernel

[Dmitry Torokhov]

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

Re: Null dereference errors in the kernel

[Daniel Drake]

Dmitry Torokhov wrote:
> It looks like the problem is gone in the latest -git.

That explains the confusion. I was looking at the latest -git.

Daniel

Re: Null dereference errors in the kernel

[Dave Jones]

On Mon, Jul 17, 2006 at 08:49:19PM -0700, Thomas Dillig wrote:

 > 144 drivers/char/agp/ati-agp.c
 > NULL dereference of variable "ati_generic_private.gatt_pages" in 
 > function call (drivers/char/agp/ati-agp.c:ati_free_gatt_pages).
 
I think this is a false positive.
It's a freeing function, the other half of ati_create_gatt_pages,
which always gets called beforehand, and if that fails, we should
never get to ati_free_gatt_pages.

		Dave

-- 
http://www.codemonkey.org.uk

Re: Null dereference errors in the kernel

[Peter Osterlund]

Dave Jones <davej@redhat.com> writes:

> On Mon, Jul 17, 2006 at 08:49:19PM -0700, Thomas Dillig wrote:
> 
>  > 144 drivers/char/agp/ati-agp.c
>  > NULL dereference of variable "ati_generic_private.gatt_pages" in 
>  > function call (drivers/char/agp/ati-agp.c:ati_free_gatt_pages).
>  
> I think this is a false positive.

I don't think so. If the 'entry = kzalloc(...)' fails at line 125, the
code will set tables to NULL and retval to != 0. ati_free_gatt_pages()
will then be called with .gatt_pages == NULL and .num_tables > 0. This
will trigger a NULL pointer dereference in ati_free_gatt_pages().

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: Null dereference errors in the kernel

[Stefan Richter]

Thomas Dillig wrote:
...
> We have identified around 300 potential issues related to null errors,
...

It would be nice if you split the reports according to subsystems and
send them to addresses (especially mailinglists) given in the
MAINTAINERS file in the base directory of the kernel sources.
-- 
Stefan Richter
-=====-=-==- -=== -====
http://arcgraph.de/sr/

Re: Null dereference errors in the kernel

[Luiz Fernando N. Capitulino]

On Mon, 17 Jul 2006 20:49:19 -0700
Thomas Dillig <tdillig@stanford.edu> wrote:

| [4]
| 239 drivers/usb/misc/usblcd.c
| NULL dereference of variable "urb".

 This is a false positive.

 The tool is not taking the return statement into consideration
(and usb_free_urb() checks if the urb variable is NULL before deferencing
it).

-- 
Luiz Fernando N. Capitulino

Re: Null dereference errors in the kernel

[Andreas Schwab]

"Luiz Fernando N. Capitulino" <lcapitulino@mandriva.com.br> writes:

> On Mon, 17 Jul 2006 20:49:19 -0700
> Thomas Dillig <tdillig@stanford.edu> wrote:
>
> | [4]
> | 239 drivers/usb/misc/usblcd.c
> | NULL dereference of variable "urb".
>
>  This is a false positive.

It is not, for 2.6.17. But the bug has already been fixed some time ago.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Null dereference errors in the kernel

[Luiz Fernando N. Capitulino]

On Tue, 18 Jul 2006 23:30:43 +0200
Andreas Schwab <schwab@suse.de> wrote:

| "Luiz Fernando N. Capitulino" <lcapitulino@mandriva.com.br> writes:
| 
| > On Mon, 17 Jul 2006 20:49:19 -0700
| > Thomas Dillig <tdillig@stanford.edu> wrote:
| >
| > | [4]
| > | 239 drivers/usb/misc/usblcd.c
| > | NULL dereference of variable "urb".
| >
| >  This is a false positive.
| 
| It is not, for 2.6.17. But the bug has already been fixed some time ago.

 Wooops. Very true. Looked in current Linus' tree. Sorry for that.

-- 
Luiz Fernando N. Capitulino