https://sandstorm.io/news/2016-10-25-cve-2016-5195-dirtycow-...
Of course, if you have evidence to the contrary, we'd all like to know about it!
(You are technically correct that the writes can come from another thread rather than another process, but the important part is that it has to go through one of those interfaces.)
> Please note that this mitigation disables ptrace functionality which debuggers and programs that inspect other processes (virus scanners) use and thus these programs won't be operational.
> The in the wild exploit we are aware of doesn't work on Red Hat Enterprise Linux 5 and 6 out of the box because on one side of the race it writes to /proc/self/mem, but /proc/self/mem is not writable on Red Hat Enterprise Linux 5 and 6.
Is everyone barking up the wrong tree here?
EDIT: All of the PoCs here use ptrace() or /proc/self/mem. Why would they do that if they didn't need to?
What would have helped:
* Block ptrace() syscall using seccomp.
* Don't mount /proc, or mount it read-only.
As I understand it, those steps would close all attack vectors for this bug.
FWIW, the Sandstorm.io sandbox blocks ptrace() and doesn't mount /proc at all, so I think the bug has never been exploitable by Sansdtorm apps. (Disclosure: I am the tech lead of Sandstorm.)
I think Docker now defaults to mounting /proc read-only and blocking ptrace(), so it may mitigate this vulnerability as well, but I'm not 100% sure about that.