As part of my project, while reading the reports, I came to know about bugs of type which were not checking for null before derefencing. 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 NULL return values are tested before being derferenced or not?
What is NULL?
Oh! You should know this.
Why dereferencing null is a bug?
- It is undefined, which means anything can happen.
Types I studied?
It was only one as, a case that checks that NULL return values are tested before being derferenced.
What did I found?
Basically most of the bugs were for when memory is allocated and it may return null instead of a pointer to the memory allocated, and the objp is not checked for null before being used or before derefencing. We should check objp, before use, if we are allocating memory into it, as it may return null.
Most of the FPs were where GFP_KERNEL or GFP_NOIO or GFP_NOFS are used. But fail is not possible with these. I’ll be writing a separate blog post on them.
Have a look at this, here memory is allocated using alloc_tt_driver in serial_driver. But it is not being checked for Null before being used at line 220 as serial_driver->owner. A Bug!
Have a look at this, here Null is not possible. You can find more in the report linked above.
Stay tuned for many more cases, as I’ll be writing one post for one type of Bug. 🙂