Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Linux 2.6.30 exploit posted
Posted Jul 18, 2009 17:49 UTC (Sat) by spender (subscriber, #23067)
Additionally, the SELinux vulnerability likely affects all of your current distributions that use SELinux and is currently unfixed, so you're susceptible to exploitation of any existing null ptr dereference vulnerability.
Posted Jul 19, 2009 0:58 UTC (Sun) by mikov (subscriber, #33179)
Previous kernels aren't vulnerable to this particular bug (but may be vulnerable to other bugs that not having the gcc optimization turned off made exploitable).
Can you explain why you think that this is a common pattern in the kernel - using a pointer, and only later checking it was null?
It seems to me that it is highly unlikely to have other code affected by this problem. The bug is just horrible code and the kernel is not _that_ bad.
And that is even ignoring the fact that nobody should be doing NULL pointer deferences to begin with. My understanding is that unmapping the NULL page is a mainly diagnostic feature - not a security measure.
Posted Jul 19, 2009 22:15 UTC (Sun) by madscientist (subscriber, #16861)
int foo(struct bar *barp)
struct subbar *sb = barp->sub;
if (!barp) die...
In this context it's not so hard to see, but in a function with lots of local variables, and which has been constructed over time (as the kernel structures add more abstraction), it might not be so clear.
It is true that even the most basic static code analysis tool will find this. I remember Coverity was doing "pro bono" checking of the kernel for a while; is that still going on? Maybe they haven't done 2.6.30 yet? Or maybe this class of errors was deemed low priority?
Posted Jul 20, 2009 0:20 UTC (Mon) by jengelh (subscriber, #33263)
» but in a function with lots of local variables, and which has been constructed over time[...], it might not be so clear. [...]Static code analysis tool[s] will find this.
These days, this would probably be done with coccinelle/spatch. Does not need to be a full problem resolving patch, just one that flags it. Along the lines of the following example (I do not claim to have hit the spatch syntax right):
identifier localid, data, member
-localtype localid = data->member;
+willnotcompile localtype localid = data->member;
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds