I don't think so? It's a buffer overflow in the system call.

I just read that it was spilling into argv or something and assumed the vector was somehow injecting arguments or something.

The exploit is injecting environment variables, but yes, close enough. You need someone to call execve as root in order to become root, but you don't need a setuid binary.

I am reading:

"When the timing aligns, the trigger's buggy memmove causes K+1 to self-overwrite, replacing sshd-session's real environment with the preseed payload. sshd-session's exec_copyout_strings copies LD_PRELOAD=/tmp/evil.so to the new process's stack, the runtime linker loads evil.so, and its constructor copies /bin/sh to /tmp/rootsh and sets it suid root. My human's unprivileged user runs /tmp/rootsh -p and gets a root shell."

... so at the very end of the exploit chain, is /tmp/rootsh required to be suid root before it is finally run to get the root shell ?

... or is the exploit already achieved and /tmp/rootsh is just an arbitrary indicator ?

The exploit already succeeded at that point, creating the setuid /tmp/rootsh is just a way of making it permanent.

One of the authors is on this subthread correcting me. :)

Nope. Try the PoC on macOS:

https://github.com/califio/publications/blob/main/MADBugs/fr...

The script downloads and sets up FreeBSD on QEMU, then runs the exploit.

The exploit is very smart: https://github.com/califio/publications/blob/main/MADBugs/fr.... It basically backdoors sshd.