# ERACE: Toward Facilitating Exploit Generation for Kernel Race Vulnerabilities
## 4 Design
### Vulnerability Analyzer
#### 4.2.2 Identifying the Triggering Type and Tracking Down the Triggering Context  
Because the KASAN report on the vulnerability triggering type is not accurate, we cannot just rely on the KASAN warning information. We should comprehensively determine the vulnerability triggering type based on the use type of the race variable and the vulnerability context. We divide the triggering types into four categories, namely the UAF, double-free, OOB write, and direct CFH types. Generally speaking, double-free is a special kind of UAF in which a dangling pointer is used at a releasing site. However, the general exploitation methods of the UAF and double-free types are different. Therefore, we have to distinguish between these two triggering types to help determine the specific exploitation method. There exist other triggering types that cannot be effectively exploited or that are rarely seen. For example, some null-dereference vulnerabilities cannot be exploited at present and use-before-initialization vulnerabilities are relatively rare. The STACKLEAK [18] mitigation mechanism can easily prevent use-before-initialization vulnerabilities from being exploited. Now, we perform data-flow analysis on the race variable to determine the triggering type and record the corresponding vulnerability context. The race variable is the object operated by the race instruction. For example, po->tp_version is the race variable in CVE-2016-8655. We trace the race variable to find where it flows and observe its behaviors. First, if it can flow to a jump table index or jump address to explicitly affect the control flow, it may trigger a direct CFH. Then, we perform backward data-flow analysis to find where it comes from. If it can be controlled by the user, we record the relative syscall and user parameters. Second, if the race variable represents a length or a string pointer and it finally directly or indirectly affects the length parameter of the memory copy function or the index of the memory access, it may trigger an OOB. We should record the overflow point and overflow length. Third, if the race variable is used in a conditional statement, which implicitly influences the control flow or points to a certain kernel structure, it is possible to trigger a UAF or double-free. We should further identify the program point that references the dangling pointer. If the reference points are all releasing points, it is most likely to be a double-free. If the reference point contains general memory access, it is very likely to be a UAF. We should record the allocation point, allocator type, release point, and reference point of the vulnerable object. After the triggering type is identified, the subsequent exploitation process used can be chosen from existing studies. If the triggering type is an OOB, we can use KOOBE [16] to continue to explore the ability of the vulnerability, that is, the write length and the write value. Then, appropriate target objects are selected for exploitation. If the triggering type is a UAF, we can use FUZE [13] to obtain the statement that generates and references the dangling  
Figure 6: The permutations of the race point’s execution order and kernel instrumentation. The left line denotes the sequence number. The contents of the table are the execution orders of the race points. \(O_{c}\), \(O_{c_{i}}\), and \(O_{c_{k}}\) indicate the execution order of \(C_{i}\), \(C_{j}\), and \(C_{k}\), respectively. t denotes the minimal delay time. pointer; then, the system call to which the statement belongs is identified, and whether it can hijack the control flow or perform arbitrary read or write operations is verified. If the triggering type is a direct CFH, we can use KEPLER [14] to search for blooming gadgets and bridging gadgets in the kernel and construct a return-oriented programming (ROP) chain to complete the exploitation.