The vulnerability is in the Linux V2 Hardware Emulation software. The vulnerability was found via using custom modifications to syzkaller. Additionally, KernelAddressSanitizer (KASAN) detected a UAF on some linked list manipulations.
Essentially, an assumed to be locked thread could be accessed via other methods. This creates a race condition that can turn into a UAF.
The exploitation is difficult, particularly because it is a race condition. So, in order to hit the race condition to get the UAF, a heap spray was used. This is simply just spraying a ton of attempts until one of them eventually works.
To hijack execution, a painful amount of reversing had to be done. Eventually, it was found that one of the objects subobjects (that could be overwritten) had a function pointer. But, there were some issues with this. Hijacking the control was possible but the pointers (of the fake objects) needed to be in Kernel space.
To get the objects in Kernel space (which took a while to figure out). First, the Kernel logs (viewable in userspace) were leaking addresses in the Kernel. Because of this, it was possible to predict the next location of the address. Additionally, in order to keep data in Kernel space, a trick was used: put the payload in the Kernel stack and call the userfaultfd to keep it there.
After this, it explains the mechanics in which the race conditions were happening. Essentially, it is creating the leak, waiting, spraying, waiting and, finally, trigger the final payload.
Uses a stack pivot, in order to get RSP in a better place (overwrite RSP with a controllable value in RDI). Then, jumps to run_cmd within the Linux source code. At this point, we have passed this function a shell script (which runs in Kernel land) to run whatever we want!
The final trick was to stop the thread at this point. Otherwise, the Kernel crashes, resulting in an obvious 'something bad happened' to the user.
Overall, this is a wonderful exploit! It really goes into the details on how to make a race condition consistent.