As far as I have been able to figure out, you can only truncate directories due to this bug,
not write arbitrary contents to them. There are checks in place in the write() system call
that checks that you actually have opened the file with O_WRONLY or O_RDWR (but having those
set would stop you already in the open() call).
The bug also only allows you to truncate directories to which you already have write
permission. I.e, you can truncate /tmp, but not /etc.
However, that is probably exploitable enough. After clearing /tmp, you could then create a
new /tmp/.X11-unix/X0 socket going to your own program. Any new X client would connect to
that and talk to your program, which could act as a man-in-the-middle, grabbing the X cookie
and gain access to the X server. Or you can replace the socket to someone's ssh-agent, and
thus grab all ssh keys added after that. (Normally, the sticky bit on /tmp prevents you from
doing this.) I wouldn't be surprised if you can attack other programs too, by replacing
temporary files they don't expect to be replaced...