Immutable distributions, in Linux parlance, run on a read-only root filesystem that is swapped for the next boot if there are any updates. Usually, you can use one or more snapshots to roll back to the (or a) previous version if an update fails.
What this attack is doing is not helped by immutability under that definition: it's entirely in memory and works only as long as the target executable is in memory. It first reads the target executable into the disk cache and asks a specific kernel module to encrypt it with a splice() system call to avoid copying the disk cache page elsewhere. Except that specific kernel module overwrites 4 bytes past the end of its buffer, so if you ask for a 32-byte buffer starting at /usr/bin/su byte 696, you can write bytes 728-731, directly in the system's disk cache. And then you can just keep looping to write any arbitrary string of multiples of 4 bytes into what the kernel considers to be a current copy of the latest data on disk for that file, up to that file's size. It's also not marked as dirty, so it never gets written to disk and only gets evicted with normal disk cache operations.
Now, while the attack only works as long as the targetted executable is in the disk cache, that's not much of a problem in practice, because the disk cache often survives the few microseconds needed to set up the required system calls. And once you finally execute the binary as setuid root, Linux consults the disk cache, finds it has a version already and runs it. But you now have a root shell, all without a single disk write, and can now begin to remount filesystems read-write to establish persistence.
Answering a sibling comment, write-xor-execute (W^X) memory doesn't give any protection here either, because a kernel module is performing the write. Write protection on executable pages is provided by the CPU operating in user mode.