As part of my project, while reading the reports, I came to know about bugs, using X after freeing it. There were many in the versions 2.4.x and 2.6.x. I was also required to list FPs (false positives) by Coccinelle. This post will be about, what I found for the case of using freed memory.
What is kfree?
kfree frees previously allocated memory. If objp to be freed is null, it is no-op.
Why using freed memory is a bug?
- Using freed memory can cause a program to crash.
- Can lead to write-what-where-condition
- Can have consequences like corruption of valid data and the execution of arbitrary code
- and many other problems.
Types I studied?
I studied two types:
- Results for the case of a use after kfree
- Results for the case of a use after a function that directly or indirectly calls kfree
What did I found?
In case of bugs, most of them were similar. In most of the bugs if at line number a (<b) variable X is freed using kfree, some or the other member of it is accessed at line number b (>a).
In the FPs by Coccinelle, many were for the case when the variable freed is acceesed only after a null check in if condition (ex 1285 and 1289). Some were due to Coccinelle didn’t considered that stringize operator is being used and hence a new name will be used and not the name of the variable which is kfreed.
You can find bugs of each type above in the report linked. Here is an example: Have a look at this, dev is kfreed at line 150. But at line 159 dev->bus->number, dev->devfn are accessed!
Look at this. addr is freed but in the next line, addr is not used. Why? because the macro is using a new name generated, using stringize operator.