It's been a while, but IIRC Docker wasn't affected by Dirty COW because they mount /proc read-only. (Sandstorm was unaffected because it doesn't mount /proc at all.)
FWIW I haven't kept the security non-events up to date over the past year or two. There was at least one Linux kernel bug I can remember last year (CVE-2017-5123) that allowed a breakout from all container engines, because waitid() is too important a syscall to block. However, the vulnerability was newly-introduced and hadn't made its way into too many distros before it was fixed.
DirtyCOW requires either ptrace or /proc/PID/mem, neither of which are accessible natively via gVisor. Even if they were, the VDSO is isolated, which was a good vector for privilege escalation.
I don’t think “locked down namespaces” means anything. Sandstorm was not vulnerable because it doesn’t mount /proc and doesn’t allow ptrace.
however, i think docker may have been vulnerable against dirty cow. [https://github.com/gebl/dirtycow-docker-vdso] i'm not sure if this was before or after jessie's work on securing docker.
also, i don't think gvisor would have been vulnerable to dirty cow. it looks like it 'gates' all the mmap/munmap/madvise syscalls through a sentry process which does some kind of emulation of virtual memory through some magic. [https://github.com/google/gvisor/blob/797cda301677abc8523d5a...]. like ultimately, i think mmap() system calls need to be executed in the monitored process but i think they are only done by the sentry using ptrace and if the sentry dies then i assume it is the root of the pid namespace so the process it is monitoring is killed as well.