How detrimental is a NULL pointer dereference vulnerability today?

Question

Recently I have been reading about the implications of NULL pointer dereferences in kernel code (often LKMs/modules), specifically escalating privileges to root via mmap()ing the NULL page and then memcpy()ing some shellcode which calls commit_creds(prepare_kernels_cred(0)); (or whatever else) from user-land to cause subsequent code to be executed in context of the root user (usually to spawn a root shell). This was a very popular exploitation method around over a decade ago.

A mitigation, mmap_min_addr, which prevents mmap()ing of low pages was introduced, and people (of course) found ways to bypass it (the articles I read were all in 2009). However, there are (seemingly) no (known or public) methods of bypassing this mitigation (and of course other kernel-hardening causes memory-corruption bugs such as this to become more difficult or completely infeasible too).

Given this, just how detrimental are NULL pointer dereferences today? It seems as though the best one can leverage is denial-of-service (in a modern kernel with mmap_min_addr enabled [perhaps neglecting ASLR, DEP/NX, SELinux/AppArmor/PaX/grsec, etc.]). Is it possible to leverage privilege escalation in particular environments? (Excluding disabling of mmap_min_addr, of course). And if so, what are some examples?

Answer 1

These days null pointer dereferences can only directly be leveraged as denial-of-service conditions, as the zero page is always protected against being allocated. There are cases where the dereferenced pointer is not null, but does point to deallocated memory (e.g. UAF in a JIT), and these can generally be leveraged to gain LPE or RCE in certain cases - the latter mostly being applicable to JavaScript engine vulnerabilities.

That said, triggering a null deref can often have secondary effects outside the scope of DoS, e.g. producing a stack trace or core dump that leaks sensitive data in a way that an unprivileged user can access it.