In the Windows Operating System, you can create symbolic links using kernel syscalls. Once a reference has been made, the handle is passed back to the user in order to use. symlinks can also be deleted.
When a symlink is being created, the valid handle is created quite early in the process. Why is this problem? An attacker can predict this handle value and access it from another thread! Because the lock was never applied (I mean, it is not even finished being created), the rest of the creation process can used an unexpectedly changed symbolic link handle.
In the proof of concept, the author has one thread continually closing (removing) symlink handlers and the other one creating them. Eventually, the race will be won, resulting in a crash in the symbolic link creation handler.
I had never considered this before! In the future, I will remember the creation process as an interesting place to validate that locks are done properly.