Stable kernels 2.6.27.27 and 2.6.30.2

There are some cases where this pattern makes sense. For example, you might dereference a pointer which you know to be non-NULL by design, and then pass it to a generic macro intended to work where that isn't always the case. As things are, the compiler reasonably takes the dereference as a sign that the programmer knows the pointer to be non-NULL, and thus optimizes away the presumably redundant test.

With the recent changes this optimization is no longer performed, which--as a fix for a single obvious logic error in the code--will lead to less efficient code in general without solving the core issue, which is the failure to test for NULL before dereferencing a potentially-NULL pointer. It would make more sense to either guarantee that execution will not continue following a NULL dereference or classify all NULL dereferences as exploitable vulnerabilities (or both).

Because optimizers can be clever and might determine that knowing that something is non-NULL can allow some (legit) optimization, but the programmer shouldn't be obligated to do that optimization by hand to get the code to compile.

The reason that the kernel wants this option but userspace doesn't is because, in kernel space, an attacker might map something into address 0, so assuming that null pointer dereferences always crash is dangerous. In userspace, on the other hand, you've already been owned by the time someone maps something at address 0.

If there are no such cases, of course.

But examples abound. Simple one from http://lwn.net/Articles/342226/:

inline char foo(char *p) { if (p == 0) return 0; else return *p; }
char bar(char *p) { *p = 2; return foo(p); }
int main() { char c = 0; return bar(&c); }

I already see GCC bugzilla fill with complaints when it would no longer compile this (perfectly valid) piece of code with a redundant NULL pointer check...