# ERACE: Toward Facilitating Exploit Generation for Kernel Race Vulnerabilities
## 7 Related Works  
As mentioned above, the objective of this paper is to assist in the process of exploiting kernel race vulnerabilities. Therefore, the related works are mainly divided into three categories, namely race vulnerability detection, automatic exploit generation in the user space, and kernel vulnerability exploitation. Below, we discuss the existing works in these three categories in detail. **Race vulnerability detection. ** There are a lot of studies on detecting race vulnerabilities, and feature modeling and dynamic detection techniques for race vulnerabilities are very helpful for race exploitation. These techniques are mainly divided into two categories: static analysis and dynamic analysis. Refs. [30; 31; 32] adopted static analysis techniques. Among them, Relay [31] proposed the concept of a relative lockset, which makes the function summary independent of the calling context so that it can perform easy-to-parallel modular and bottom-up analyses. Ref. [30] was based on the Coccinelle engine and used static pattern matching to detect a special kind of data race, called a double-fetch vulnerability. It matched the kernel function that calls copy_from_user() or get_user() multiple times to read data from the user space at the same address and then manually analyzed these matched functions. Ref. [32] formalized the double-fetch vulnerability, of which the two read operations have a spatial overlap and the overlapping variables have control dependence or data dependence. Then, static analysis and symbolic execution were performed on the LLVM intermediate representation. The advantage of static analysis is that it is scientific in race vulnerability feature modeling and has great scalability. The disadvantage is that it has a high false-positive rate and relies heavily on manual confirmations. Refs. [10; 33; 34; 35; 36; 37; 38; 39] applied dynamic analysis techniques. Bochspwn [38] is a system-wide memory monitoring tool implemented on a Bochs \(\times\)86 emulator, which is capable of detecting kernel double-fetch and information leaks. ThreadSanitizer [39] is an execution tool integrated into gcc [40] and clang [41] compilers that can detect multi-thread data race vulnerabilities at runtime. The goal of [33; 34] was to detect concurrency vulnerabilities. The former proposed the coarse-grained interleaving hypothesis, which improves detection accuracy and reduces time costs. The latter defined relaxed exchangeable events, which can detect three types of concurrency vulnerabilities, the UAF, null-pointer-dereference, and double-free vulnerabilities. The innovation in [10; 35] was to explore thread interleaving, which applies modified QEMU that can be used to set breakpoints to control thread interleaving. However, the former does not first determine the suspicious race instructions, resulting in a large search space. The latter proposed a deterministic thread interleaving technique, which modifies qemu and implements three hypercalls to schedule several virtual CPU cores to run and interrupt. However, it can only control thread interleaving on different CPU cores, whereas our exploit must run on one specific CPU to improve the success rate of heap spraying. Thus, the hypervisor-based solution does not promote our exploit debugging. The innovation in [30; 37] was to improve the traditional fuzzing technique to adapt to detecting race vulnerabilities. [PERSON] [36] introduced a new coverage tracking metric, namely alias coverage. [PERSON] [37] introduced a new instrumentation mechanism and optimized the process of seed selection. The mechanism gives priority to the seed that can trigger new code coverage or a new thread context. The advantage of dynamic analysis is that it can directly generate input that triggers vulnerabilities, but the disadvantage is that it has poor scalability and slow speeds. **Automatic exploit generation. ** Kernel vulnerabilities are more difficult to exploit than vulnerabilities in the user space.