If I understand correctly, the fact that if a page is mapped by a process at address zero allows both userland and kernel code to trigger unexpected code paths, since page access isn't exclusively kernel or userland. The optimizations mentioned in TFA add even more potential for issues, since userland code could control pointers in that zero page to point to arbitrary data in userland that the kernel can read.
This is fascinating, I didn't know it was possible to share pages between userland and the kernel, and always assumed those two were strictly segregated.
Yep. Something I didn't mention is that if you just try to allocate memory without using MAP_FIXED to force a particular address, the kernel will never choose address 0, regardless of the value of mmap_min_addr. That's true even if the entire rest of the address space is filled. Therefore, userland programs can rely on accesses to address 0 causing a fault unless they specifically ask to map it, which makes the compiler optimization in question perfectly reasonable for most of them. After all, a userland program doesn't worry about being exploited by itself.
(There's still potential for unexpected behavior in those userland programs that do map 0, like wine and dosemu. Even if those programs themselves are compiled with -fno-delete-null-pointer-checks – I'm not sure whether they are – they link to system libraries which aren't. Oh well.)
If I understand correctly, the fact that if a page is mapped by a process at address zero allows both userland and kernel code to trigger unexpected code paths, since page access isn't exclusively kernel or userland. The optimizations mentioned in TFA add even more potential for issues, since userland code could control pointers in that zero page to point to arbitrary data in userland that the kernel can read.
This is fascinating, I didn't know it was possible to share pages between userland and the kernel, and always assumed those two were strictly segregated.