I have recently came across (well, not entirely by myself… cheers Nahuel!) a fairly (un)common problem related to performing ring0-to-ring3 transitions, after a successful kernel vulnerability exploitation. As I have managed to come up with a bunch of possible solutions, and even write example code for some of these, today I would like to present my thoughts, together with some brief explanation.
Before trying to find a reliable solution to the problem, it should be clearly stated first. And so, we are considering a 32-bit Windows NT-family version (one of the supported ones), suffering from a stack-based buffer overflow inside one of the system call handler functions. The attacker is able to overwrite memory placed after a fixed-size buffer, including the stack frame, return address, syscall arguments and anything else reachable from this point. As opposed to the reality, we assume that there is no stack protection (i.e. a cookie) implemented, so the security flaw can lead straight into malicious code execution and system compromise. Furthermore, the overflow is triggered right inside the syscall handler, not a nested function of any kind.
The following ascii picture, presenting the stack layout at the time of the overflow, should give you a better insight of the described scenario: