foo = sk->bar;

if (!sk)
error();

The compiler reasoned that the if() statement could be optimised out, because if sk was NULL then the earlier derefence would have faulted. This created an exploitable NULL pointer dereference, because userspace can map pages at address zero and then call into the kernel.

There is a good paper by Thomas Reps from the University of Wisconsin that covers some of these differences. It is WYSINWYX: What You See IS Not What You eXecute. Ref: http://www.cs.wisc.edu/wpis/papers/wysinwyx.submission.pdf

Here is an excerpt:

Less widely recognized is that even when the original source code is available,
source-code analysis has certain drawbacks [Howard 2002; WHDC 2007]. The reason is that computers do not execute source code; they execute machine-code programs that are generated from source code. The transformation from source code to machine code can introduce subtle but important differences between what a programmer intended and what is actually executed by the processor. For instance, the following compiler-induced vulnerability was discovered during the Windows security push in 2002 [Howard 2002]: the Microsoft C++ .NET compiler reasoned that because the program fragment shown below on the left never uses the values written by memset (intended to scrub the buffer pointed to by password), the memset call could be removed—thereby leaving sensitive information exposed in the freelist at runtime.

memset(password, ’’, len);
free(password);

=>

free(password);

Such a vulnerability is invisible in the original source code; it can only be detected
by examining the low-level code emitted by the optimizing compiler. We call this
the WYSINWYX phenomenon (pronounced “wiz-in-wicks”): What You See [in
source code] Is NotWhat You eXecute [Reps et al. 2005; Balakrishnan et al. 2007;
Balakrishnan 2007].

WYSINWYX is not restricted to the presence or absence of procedure calls; on
the contrary, it is pervasive.

-Chris