I'm not a linux kernel expert, but I am familiar with the concepts involved and I read Linus' comment and the diff. I'll give it a go - perhaps people can correct me if I get it wrong and we'll hash things out together.
Copy On Write is an internal memory concept where, primarily for performance reasons, operations that make a copy of a section of memory don't actually get their own copy unless and until they make a change to that memory - at which point, you quickly make their copy, make the change to that and hand it back to them. The advantage is that you don't have to do the work of making the copy unless and until they actually change it - faster, less memory usage, better caching.
The bug here is in the code that does that copying. It appears that there is a race condition in that copy (or actually in the bookkeeping around that copy). A race condition happens when two different processes or threads are accessing the same resource and step on each other. In this case, what happens is that the memory is flagged to be writeable before it is actually copied - if two threads are working very closely to each other, the second can take advantage of the writeable flag and actually write to the original memory, not the copy.
The exploit is that this lets a process elevate itself by getting write access to the kernel's own understanding of it. The kernel knows what user each process is running at - by taking a copy of that memory that kernel is using to store that info using Copy On Write, then using this Dirty COW bug, they can actually write the user info into the kernel's own copy. So they write that the process is being run as root.. and then they can do anything.
The demo program uses that to write to a file only writeable by root, but it could have done literally anything. The fix was to separate out a new flag saying they are doing a CopyOnWrite, instead of using the Write flag for both.