Though I specifically noted the stack overflow case, I was rejecting the general notion that the null ptr dereference was due to some attacker-influenced manipulation or control of kernel data.
These bugs generally crop up from having incomplete handling of all possible cases of working with a pointer. The most fruitful ones are the bugs where it involves using a null pointer to a structure containing a function pointer, or simply a null function pointer itself. The kernel has a ton of the first case: it's the way in which abstractions are made. These grant trivial arbitrary code execution on x86 (just map your code at address 0 and it gets executed in kernel context), whereas in other cases these bugs can be used to provide the kernel with trojaned data -- though the usefulness of this for DoS or privilege elevation has to be determined on a case-by-case basis.