$ (sleep 10; /tmp/a.out id) &

$ -> the end of the prompt of a "normal" (i. e. non-root) user

() -> run everything inside in a forked subshell of the current shell

sleep 10 -> "block"/sleep for 10 seconds via the `sleep` executable in your $PATH

; -> after the left-hand side terminates, proceed with the next command on the right-hand side

/tmp/a.out id -> fork and exec the program located at /tmp/a.out with the literal byte sequence "id" on its argument vector

& -> run this command (the whole subshell that () requests) as a background job

When the user exits the shell that spawned the subshell, the whole process group will receive SIGHUP. The backgrounded subshell will still continue running, and after its `sleep` child process terminates, go on to run `/tmp/a.out`.

As far as I understand it:

A background subshell is started that waits 10 seconds and then runs a program with the input "id". That program uses ioctl to send characters to the current TTY.

Since the user exited back to the root shell before the program executed, the `id` command is typed and executed on the root shell.

It's waiting, the "tty" command which is invoked a "a.out" causes the tty to receive the sequence of characters specified -- in this case "id\n". The vulnerability here is that if, as one user, you switch user contexts and then later (10 seconds, in this case, hence "sleep 10") the command interacts with the tty over the file descriptor that had been given to the child process and not killed when you exited the shell that spawned it.

It runs the command in a (subshell), in the background&.

This is to make the process survive the subsequent logout.

Because this process inherited terminal fds from the parent, it can continue accessing the logged out terminal (now root).