CVE-2022-0435 is a remotely triggable buffer overflow in the Transparent Inter-Process Communication (TIPC) stack of the Linux kernel. Within the structure tipc_mon_domain, there is a field that holds an array of domain records (u32 members[64]); a domain record is the network topology. However, the bounds of the array being written to are never checked.
What are the constraints on this overflow? Several of the fields, such as len, gen and a few others have constrained values. the members field, with our overall, can be arbitrary. The author says that this exploit would require an additional vulnerability to break KASLR and the stack canaries.
This overflow takes place on the stack and the author is exploiting a x86_64 machine. As a result, we can control many of the registers being replaced at the end of the stack frame, including the RSP and RIP. Since NX, SMEP and SMAP are turned on, we have to be clever with our exploitation. This is done by calling set_memory_x($RSP & ~0xFFF, 1) in order to make the stack page executable. Once this is done, we can execute our shellcode from the stack overflow before.
Are we done? Not really! We still need to clean some things up first. The author puts a few things into consideration: stack frame clobbered and locks that need to be released. With this, we can fix the locks and frames, then jump to the closest non-destroyed stack frame.
Even once we have cleaned up the code, we still need to get into the process context. Apparently, the networking stack is completely isolated from this. In order to hook into the userspace, syscall hooking can be done. Once a syscall has been hooked by writing to the sys_call_table, we can execute code in userspace.
The author of this post added shellcode to add custom code to an arbitrary userspace process in its own mmap program. Interesting stuff to write an remote exploit for the Linux networking stack.
The mitigations heavily restricted this; the remote nature made this much harder to exploit. In particular, the stack canary and KASLR caused problems. Overall, good write up on a Linux Kernel stack based buffer overflow and the exploitation of it.