The simple mitigation is to not have local users who will hack your machine.
If you run a server, an exploit of the server software (nginx, PHP scripts, Ruby on Rails, etc.) will provide local non-root access, which you can then root.
If you run your server software in Docker, then the host system's binaries aren't exposed. That means an attacker can't modify the disk cache for /bin/su and then su to root; he can only modify the disk cache for /bin/su or glibc from e.g. the debian:jessie image that the Docker image the container used is based on. Elevation in the same container is useless: anything mounted read-write is likely already writable by the software the attacker exploited in the first place, so they have that access; and modifying the system is pointless, since you can just destroy and recreate the container in 10 seconds.
A container exploit might give a cross-container exploit to all containers eventually descended from the same version of the same base image (e.g. everything ultimately built from that release of debian:jessie), but it's tricky. You can modify e.g. /usr/sbin/nginx and send a reverse-shell to all nginx containers; or you can modify glibc and get it into everything using the same base image (because it's from the same disk blocks, thus the same disk cache). Either of those has to use the existing memory space (can't add empty memory pages or use anything outside the file), replace code in an existing function, and not outright crash (or the container terminates and all processes end immediately); and a glibc modification would make your reverse shell kind of useless (bash would just re-exploit and call a new reverse shell).
Escape to the host system is as impossible as it is without this exploit, so there's that.
So, for some server software configurations, this is diminished to the point of uselessness. For others, they get the www-data user and then su straight to root.