vnik@ubuntu:~$ ./cve-2016-0728 blah [+] uid=1000, euid=1000 [+] Increfing... [+] Finished increfing [+] Forking... [+] Finished forking [+] Caling revoke... uid=1000, euid=1000 $
So you've tried the PoC(waiting for approximately 30-60 min depending on your CPU) to check whether your system is vulnerable and the exploit that "imperils tens of millions of PCs, servers, and Android phones" didn't work for you? It's amazing how news can stretch the truth for a story.
People are talking about SMEP/SMAP and these being the reasons for the exploit not working. So let me get this straight: even if your CPU supports SMEP/SMAP or your have incorrect addresses for prepare_kernel_cred() and commit_creds(), you would see a page fault, double fault, or some kind of oops (assuming this a working exploit code). In some cases, (depending on the address the kernel execution flow is redirected to), your system may recover after the oops or double fault and require a restart.
The truth is refcounter overflows can be somewhat tricky to exploit due to the RCU implementation and ordering these RCU calls. I've described this problem in my post. I believe this was the first refcounter overflow exploit. However, I didn't describe the technique for ordering these RCU calls to achieve a reliable counter overflow, i.e., counter decrement followed by the null check and free. The exploitation was a bit more complicated since the vulnerable object had no function pointers and was heavily used by the OS, so we had to resort to the SLUB free pointer manipulations.
The point is this vulnerability can be exploited (and the exploitation process can be made somewhat reliable) but not with the provided PoC where they're trying to order RCU calls with sleep()s :) The PoC was apparently tested by Perception Point on 3.18 64-bit. This PoC may have worked for Perception Point in a controlled environment with a debugger attached.
The question for most admins now is how to protect against this bug if there are no patches available yet? Install and configure grsecurity. I'm sure will see more refcounter overflow exploits in the near future, so it's a good idea to enable grsecurity even if your kernel is not vulnerable.
P.S.: Please stop saying this a remote threat that affects millions of Android devices.