The full write-up can be found here and should be fairly readable for users of this forum.

Some quotes that I thought were interesting:

With a heap corruption as a primitive, two FILE structures malloc()ated in the heap, and 21 fixed bits in the glibc’s addresses, we believe that this signal handler race condition is exploitable on amd64 (probably not in ~6-8 hours, but hopefully in less than a week). Only time will tell.

So 64-bit systems seem to be a bit more resistant to this it seems? But I can’t be completely sure given how much I’ve read about this yet.

This vulnerability is exploitable remotely on glibc-based Linux systems, where syslog() itself calls async-signal-unsafe functions (for example, malloc() and free()): an unauthenticated remote code execution as root, because it affects sshd’s privileged code, which is not sandboxed and runs with full privileges. We have not investigated any other libc or operating system; but OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001.

It seems that non glibc-based systems also could be vulnerable, but they have not yet tried to demonstrate it yet (or have tried and not been successful).

And OpenBSD wins again it seems.