Linux 2.6.30 exploit posted [LWN.net]

Linux 2.6.30 exploit posted

Posted Jul 19, 2009 0:58 UTC (Sun) by mikov (subscriber, #33179)
In reply to: Linux 2.6.30 exploit posted by spender
Parent article: Linux 2.6.30 exploit posted

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.

(Log in to post comments)

Linux 2.6.30 exploit posted

Posted Jul 19, 2009 22:15 UTC (Sun) by madscientist (subscriber, #16861) [Link]

I've been seeing a series of patches going in on various mailing lists that fix problems like this over the last few days. The issue is that the kernel uses lots of complex data structures, and programmers want to simplify the code by creating local variables. So, you might see a function like:

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?

Linux 2.6.30 exploit posted

Posted Jul 20, 2009 0:20 UTC (Mon) by jengelh (subscriber, #33263) [Link]

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

@@
type localtype
identifier localid, data, member
statement s
@@
-localtype localid = data->member;
+willnotcompile localtype localid = data->member;
 if (!data)
   s;
@@