# ERACE: Toward Facilitating Exploit Generation for Kernel Race Vulnerabilities
## 2 Background and Challenges
### The Process of Exploiting Race Vulnerability  
The process of exploiting a data race is shown in Figure 1. Suppose that a researcher obtains a PoC that can trigger a data race but cannot successfully exploit the vulnerability yet. A successful exploitation means that we can escalate privileges from ordinary users to superusers. For a vulnerability caused by a data race, the race point is equal to the vulnerability point, whereas the vulnerability triggering point is equal to the crash point. The vulnerability point is different from the crash point for most data races. However, for most common kernel vulnerabilities, such as an OOB write and UAF not caused by data races, the vulnerability point is no different from the triggering point and the vulnerability point. Researchers need to perform the following steps to successfully escalate a privilege. First, the researcher should find the root cause of a race vulnerability based on the PoC, that is, the race instructions that accessed the same variable or memory, and determine  
Figure 1: The typical workflow of crafting a working exploit. \(\blacklozenge\) Identify the race instruction; \(\blacklozenge\) Determine the timing relationship of the race instruction and the triggering type and select the appropriate exploitation method; \(\blacklozenge\) Determine how to check whether the race condition and heap spraying are satisfied; \(\blacklozenge\) Construct the exploit. Note that the zigzag line indicates the kernel execution, and syscall_A and syscall_B denote the system calls that are attached to the occurrence of the race points in the two threads, T1 and T2. syscall_x can be syscall_A or another system call. the system call to which the race instruction belongs (see  in Figure 1). This is conducive to the subsequent analysis and the construction of competing threads. Determining the root cause of the vulnerability requires analyzing the source code, understanding the logic of the source code, or completing a reverse analysis based on the output of the stack traceback information by the kernel address sanitizer (KASAN) [11] at the crash point. For most data races, crash points are different from race points and they may even be far away from each other. Hence, it is not easy to locate race instructions. Second, the timing relationship of race instructions and the triggering type of the vulnerability need to be determined (see  in Figure 1). Competition is the cause, whereas triggering is the result. A pure race is not necessarily exploitable. However, if a race can lead to UAF or OOB write vulnerabilities, then the race may be exploitable. Its exploitability also depends on the specific vulnerability context. Third, the method of checking whether the race and heap spraying were successful needs to be determined (see  in Figure 1). Assuming that the race triggers a UAF issue and only after the race succeeds, heap spraying can be used to complete control-flow hijacking and privilege escalation. We can directly perform heap spraying without confirming whether the race succeeded or not and just confirm whether the privilege was escalated at the end of the exploit. However, what happens when the race fails? We have to restore the heap-space layout and perform competing and heap spraying again, which are both time-consuming and greatly prolong the entire exploitation process. What is worse is that the heap-space layout might have been destroyed once the heap spraying occurred, making it difficult to recover the heap-space layout. Sometimes the system may directly crash and the exploitation cannot continue. Similarly, proceeding to the next exploitation stage without checking whether the heap spraying was successful may also reduce the success rate of the exploitation. Fourth, the exploitation strategy is determined and the final exploitation is finished (see  in Figure 1). According to the recognized race instruction and the relative system call, we can construct competing threads.