BLASTing Linux Code

Jan Tobias Mühlberg and Gerald Lüttgen
Department of Computer Science, University of York, York YO10 5DD, U.K.

main page | next example

Commit Overview | Files | Comments

Checking Memory Safety: Example 1

Commit Overview

Commit Key d2b0e84d195a341c1cc5b45ec2098ee23bc1fe9d
Subject [PATCH] drivers/message/i2o/pci.c: fix a use-after-free
Description The Coverity checker spotted this obvious use-after-free
Requires Linux 2.6.14 kernel source as from git://

--- a/drivers/message/i2o/pci.c
+++ b/drivers/message/i2o/pci.c
@@ -421,8 +421,8 @@ static int __devinit i2o_pci_probe(struc
- i2o_iop_free(c);
+ i2o_iop_free(c);

(purple: line numbers and function names; red: line removed; green: line added)


Unmodified sources


This is the running example used in Section 3, "Checking Memory Safety". The problem in this case is, that the pointer c is de-referenced in line 425 of the source file. However, the call of i2o_iop_free(c) in line 424 does nothing else than releasing c. De-referencing it afterwards results in undefined behaviour of the kernel. The bug has been fixed by simply swapping lines 424 and 425.

We have studied this example extensively using two different approaches. In the first place we used a temporal safety specification that ensures that the functions i2o_iop_alloc() (allocate memory for c), put_device() and i2o_iop_free() are called exactly in this sequence. Due to bugs in spec.opt this technique only worked for a manually simplified version of the source code under consideration.

In our second approach we modified the the source code of the driver in order to introduce the label ERROR by hand. Mainly, we added a status field to the struct i2o_controller and modified i2o_iop_free() not to release the pointer but to change this field. Further modifications to put_device() would then enable us to detect a wrong call order. However, BLAST failed in tracing content of our status field over the several function calls. In the paper we provide a rather simple example that shows BLAST's deficiencies in dealing with pointers.


Jan Tobias Mühlberg, $Date$