> null function pointers are only exploitable if vm.mmap_min_addr is zero,
no, if a process has CAP_SYS_RAWIO it can also evade the 0 mmap restriction (and let's ignore
the early implementation bugs of this feature). if a process doesn't yet have CAP_SYS_RAWIO,
it can 'acquire' it by exploiting another that does have it (think of X for example or any
suid root process). or alternatively, one has to use SELinux and make sure no process can be
granted MEMPROTECT__MMAP_ZERO. and all of this breaks valid userland programs, so it's not a
universal solution (it's default off for that reason).
> which should not be the case on most installations.
any statistics to back it up? remember, it needs both CONFIG_SECURITY and be set to some
in any case, i'm not sure what you were trying to say, if a bug falls into a known exploitable
bug class then it should be reported as such (or briefly explained why it's not what it looks
like), regardless of what mitigation factors may apply in a given installation. such info
belongs to vendor advisories at most, not a kernel commit message.
> I imagine getting 4G references on a task_struct would be hard without
> root privileges.
the patch fixes a few ptrace commands that can be issued by any user, not only root. therefore
it's triggerable and exploitable by any user who's not otherwise prevented from using ptrace.
as for the technical feasibility of issuing 4G ptrace calls, on a core2 a single GETREGS takes
less than 30 usec, that's less than 2 days of runtime.