Take a Step Further: Understanding Page Spray in Linux Kernel Exploitation

GFP flags serve as a means to characterize the attributes of page allocation. Different GFP flags, assigned by higher-level components, have the potential to yield different fundamental behaviors. For example, when utilizing GFP_DMA and GFP_DMA32 flags, the kernel is instructed to ensure that the allocated memory is accessible by hardware with limited addressing capabilities in DMA.

During the allocation process, beginning at the zone level, the kernel diligently scrutinizes the selected memory zone to ensure a close match with the desired attributes. A comprehensive evaluation is conducted to determine the suitability of the chosen zone for the allocation. In instances where the assessed zone is found to be unsuitable, the memory allocator may proceed to revert or fallback to alternative memory zones for allocation.

In consideration of the kernel’s design, several subsystems incorporate a function that initially sets up a buffer and subsequently triggers and writes to this buffer as needed. An example of this can be observed in the code snippet shown in List 1, which is part of the pipe subsystem.

Within the pipe subsystem, a meta-control structure responsible for buffer management is referred to as pipe_buffer. This structure employs a pointer to page(s) to locate and access the actual buffer when there’s a buffer-write request originating from user space. In the pipe_write() function’s operations, after simplification, it’s evident that the kernel’s intention is to first allocate multiple pages as required. Subsequently, these allocated pages are assigned to the page buffer pointer inside the corresponding pipe_buffer object. Finally, the function copy_page_from_iter() is invoked to carry out the specific copy-write operations.

It’s worth mentioning that when the pipe_buffer is generated and initialized, the page buffer is not allocated and assigned immediately in practice. Instead, the kernel defers the allocation of page buffers until a buffer’s copy-write request is received and processed. This represents a delay-allocation strategy employed by the kernel for page buffers.

Within the networking subsystem, the structure known as sk_buff [25] is responsible for representing network packets. To focus solely on relevant details, we concentrate on the buffer aspects and omit unrelated components. In this context, the design of the buffer can be divided into two types: linear buffer and non-linear buffer.

The linear buffer is allocated at the early stage of skb creation and primarily serves to hold protocol headers and a portion of actual data. Page allocation does not occur at this initial stage. On the other hand, the non-linear buffer comes into play when the linear buffer is unable to provide sufficient memory space for data storage. The organization of the non-linear buffer resembles multiple fragments, with each fragment maintaining a specific page as the data buffer. The kernel employs copy-write operations to transfer data from user space to these continuous page fragments.

In the relevant function packet_snd (as seen in List 2), an skb is generated by alloc_skb_with_frags() in lower level, which is called to allocate page fragments as buffers. Subsequently, the skb_copy_datagram_from_iter() function manages the copy-write process by invoking copy_page_from_iter(). When the kernel initiates the copy-write procedure, the page fragments are transformed into real page addresses using the skb_frag_page() function.

Typically, when a user-space application executes a mmap() call to establish a new mapping in the virtual address space of the calling process, the kernel primarily grants access rights to the virtual address as the return value of this call.

When we delve into the kernel implementation, we found the zero-copy mechanism facilitated by memory mapping opens up opportunities for Page Spray. Where data copy operations occur between a user process and kernel space, the boundary between these two memory address spaces often necessitates checks for operation validity and data reconstruction in the kernel space. Therefore, copy operations that traverse the boundary between user processes and kernel space can raise significant performance concerns, especially in subsystems that prioritize performance, such as the networking subsystem. To address this challenge and improve overall system performance, Linux incorporates a zero-copy design. With zero-copy, data transfer between kernel space and user processes reduces the additional overhead introduced by memory copies.

In this design, user-space processes explicitly set (ring) buffer attributes, and the allocated pages are organized into multiple page-related structures. When a process from user space perform a mmap() call, its detailed implementation and execution are redirected by the corresponding kernel function tables based on the socket’s attributes. For instance, when setting up a packet ring buffer in PF_PACKET, the mmap() call is executed by the packet_mmap() function in the kernel (as seen in List 3). In this implementation, the page-related structure it introduces is page-vector, which can be used to maintain a reference to a valid page and akin to the previously discussed skb page-fragments. The kernel first transforms a page-vector to a raw page reference in Line 8. Subsequently, in the next line, vm_insert_page() is invoked to insert the target page into the virtual address mapping space of the user space process. After this insertion, the user space process gains the right to achieve direct memory write operations to the page. In other words, at this stage, the related user process becomes capable of spraying data onto pages which allocated by the kernel space.

The zero-copy mapping mechanism leads to a page of memory explicitly shared between kernel space and user space, allowing bad actors to overcome previous limitations. What sets zero-copy mapping apart from other methods is that it inherently allocates pages for data (ring) buffers and makes them accessible to user space. In this scenario, user space gains flexible control over memory allocation and writing behaviors. For example, user space can explicitly call packet_set_ring() to specify the number of pages to allocate (as shown in List 4), where the req variable represents the ring buffer configuration request sent from the user process.

Furthermore, zero-copy mapping introduces kernel virtual address space overlaps between slab pages and zero-copy pages, providing a fundamental support for Page Spray. This means that a page discarded by the kernel heap’s slab allocator can be reclaimed through zero-copy operations and remapped to the memory space of the user space process.

To identify Copy-Write page-spraying callsites, our approach involves the analysis from root interfaces, which we categorize into two distinct types: allocation and copy root interfaces.

Allocation root interfaces primarily serve the purpose of executing direct page allocation or functioning as wrapper functions within specific subsystems to accomplish such allocations. It is worth noting that, although some page allocations occur in the kernel heap slab allocator, we do not consider those as the qualified callsites for Page Spray. The distinction here arises from the granularity of operations within the slab allocator, which operates at the object-level rather than the page-level, and in Page Spray, we consider direct page-level allocation.

On the other hand, copy interfaces are mainly associated with copy-write functions in the kernel. These interfaces are capable of transferring of data from user space to the kernel’s page buffers. Through these operations, user processes gain the capability to manipulate data at the page level. Because our data copy are based on the "benign" operations, such as copying a data to kernel space networking buffer and so on, it natively will not trigger any defense or mitigation like SMAP which is designed for enhancing islation between user space and kernel space.

To systematically identify callsites, we build a global-level callgraph in the kernel to capture inter-function control flow information. Each function call is represented as a node within this graph. We initiate our search by tracing backward from two root interface call nodes: one pertaining to allocation and the other to copy operations. As we traceback paths from root interfaces, we identify nodes where the paths intersect. These nodes are marked as potential callsites at the control flow level.

Then, to enhance the accuracy, we employ fine-grained data flow analysis. This entails conducting data flow analysis inside individual nodes. Our data flow analysis is guided by two specific instruction points. We ensure that the allocation instruction precedes the copy-write operation. Subsequently, we proceed to a search process from the allocation points to the copy-write points, with the aim of ascertaining whether the corresponding data transmission occurs between them. Specifically, if the allocation operation allocates pages and assigns them to a certain position in a control structure, and the subsequently corresponding copy-write operation writes data to that same position of the structure, we recognize this as a valid callsite.

On the contrary, when examining zero-copy calls, these are tightly linked to the function tables of specific subsystems, such as the packet_ops, in various protocol families. Therefore, in our analysis, we start by traversing the structures of these function tables at an early stage and gather pertinent information regarding function pointer members. Of particular interest is the mmap-related function pointer, which directs the mmap-execution-flow to the actual implementation in the kernel. Much like in our previous analysis, zero-copy mmap calls also contain memory remapping root interfaces. For instance, vm_insert_page() is responsible for inserting a single page into a user’s virtual memory area, and remap_pfn_range() facilitates the remapping of kernel memory for sharing with user space processes.

In the zero-copy mapping model analysis, these root interfaces are also treated as nodes at the control flow level. During our analysis, we trace back from these nodes. When we encounter a specific *_mmap function that aligns with the mmap function within a function pointer found in our collected function tables, we preliminarily consider it as a zero-copy remapping callsite. Furthermore, at the data flow level, we apply forward dataflow analysis and backward dataflow analysis. We backtrack from the allocation root interfaces to ascertain whether the same control structure is employed both in allocation and remapping. If we identify a structure that connects allocation with remapping, we recognize the callsite as a valid zero-copy remapping type page-spraying callsite.

As illustrated in Figure 2, the interface nodes represent the starting points for one-time search. While there are some raw nodes positioned beneath these interface nodes, we have opted to exclude these nodes to simplify the backtrace process. Like the pruning operation, the terminal nodes point to functions that we’ve encountered during the analysis but are not intended to be traced back to their higher parent function nodes. The introduction of this is necessary for several reasons. Firstly, in the slab allocator, there are functions that rely on the page allocator but do not directly trigger page allocation, like kmalloc(). Although indirect allocation may occur when a new slab allocation is executed, it does not align with the scenarios capable of triggering Page Spray. Secondly, the backtrace operations may have reached their maximum limit, so they terminate as we expect. Lastly, there are sections of code within the kernel that are exclusively available on specific architectures or hardware. In such cases, we dissociate the results from these code segments to ensure accuracy and relevance.

It is crucial to note that during the process of remapping invocation, there might be instances where there is no "Crossing Node." This occurs because the remapping mmap() function often follows a separate execution path from allocation. To fit this situation, we set the related "Terminal Node" for it. For example, when a mmap() call is made in the user space for a packet page buffer, it is typically executed by packet_mmap() in kernel. Therefore, packet_mmap() is considered a "Terminal Node". If the analyzer encounters this point during backtrace, it immediately stops and proceeds to analyze allocation interfaces to determine if the data flow between allocation and remapping aligns appropriately. As for allocation, we backtrace from the direct page allocation points, like __get_free_page(). Considering the multiple reference and the depth of invocation chains for these lower direct page allocation calls, when we find the tracing enter the related subsystem which is the same as previous mmap invocation, we will reset the root interface into the function in corresponding subsystem, and searching the control structure in this given subsystem. If the same control structure is found, we will compare with the control structure of the mmap operations.

Due to the page limit, we illustrate the implementation information and have a discussion. in  A.2.

To evaluate the exploitability of Page Spray, we adopt a straightforward approach. We create a Page Spray proof-of-concept (PoC) for each of the CVEs within our dataset. Subsequently, we execute these PoCs to ascertain how many of the CVEs can be successfully exploited using Page Spray with a reasonable success rate. In instances where our initial PoC fails, we conduct an in-depth examination to identify the underlying reasons and try to adapt the PoC to the specific circumstances. In cases where no modifications yield successful exploitation, we draw the conclusion that Page Spray is incapable of exploiting that particular vulnerability and provide a detailed explanation for this outcome.

Our stability evaluation experiments involve running exploits for a subset of the CVEs that are exploitable by Page Spray from the exploitability evaluation for a 1000 iterations under two distinct system operational states: the idle working state and the busy working state. The idle state represents a moderate kernel heap activity environment on the machine. This state mirrors the conditions that one would typically encounter on a standard local user’s machine. Conversely, the busy state aims to simulate a more extreme operational setting where many intensive applications and stressors are running concurrently, providing a comprehensive context to limit test the capability of the Page Spray technique. We simulate this busy working state by utilizing a benchmark program called stress-ng [40]. Due to the space limit, we describe the detail of the environment used for evaluation in Appendix §A.1.

Under these varying working conditions, we conduct a comparative analysis involving several practical state-of-the-art kernel heap exploitation techniques, including Page Spray, Single-Thread Heap Spray, and Multi-Process Heap Spray, as analyzed in K(H)eaps. This analysis serves to reveal the potential advantages or disadvantages of the Page Spray technique in the context of real-world environments.

The exploits are developed by first collecting publicly available and approved PoCs for each CVE. Then, we modify them into corresponding variants (Page Spray, Single-Threaded/Multi-Process Heap Spray) following the method we propose in Section §4. To ensure fairness, the only difference between each exploitation variant is the spraying technique itself, based on the same setups. Different types of vulnerabilities have slight differences compared to our proposed method in section 4.1, as discussed in sections 4.2 and 4.3. A step-by-step detail of one such exploits can be found in Section §8 and §A.3.

The outcome of our experiment is presented in Table 2. Page Spray demonstrated successful exploitation in 14 out of 15 vulnerabilities within our dataset. These successful exploits encompassed all three vulnerability types: UAF, OOB, and Double Free. Notably, Page Spray also effectively exploited a vulnerability on a mobile device (CVE-2022-20409) and executed cross-cache attacks (CVE-2022-2585, CVE-2022-29581).

Specifically, in the case of CVE-2022-2585, which is a relatively recent kernel heap vulnerability, traditional object spray method is unable to successfully exploit it due to the lack of precise control over the entirety of a vulnerable object and insufficient kernel information leakage. In contrast, Page Spray excels in this scenario. It effectively exploits CVE-2022-2585, and we’ll delve into this in more detail in Section §8, where we explore how Page Spray shines in addressing recent real-world vulnerabilities.

On the other hand, in the case where Page Spray failed, we conducted a deep analysis to find out the root cause. In CVE-2016-10150, the vulnerability is triggered in KVM kernel’s module. The UAF’s allocation and free happen during a single invocation to ioctl(). This situation introduces a challenging race condition with a very narrow time window. This is a corner case for Page Spray, since as demonstrated in §4, the page layout manipulation and page spraying must occur after the vulnerable object is allocated and before it is freed to effectively exploit the vulnerability. However, the stringent time constraints imposed by this case make it exceedingly difficult to set up the necessary conditions for Page Spray to be successful.

As evident from our observations of the experiment result in Table 3, in an idle system environment, the Page Spray technique demonstrates remarkable effectiveness, surpassing both the Single-Thread Heap Spray and Multi-Process Heap Spray methods. It consistently achieves an impressively high success rate, often approaching 100%, particularly in scenarios involving UAF vulnerabilities. This robust performance is noteworthy because real-world kernel heap exploits commonly occur on systems with moderate workloads. For instance, when jailbreaking mobile devices, one of the common applications of kernel exploitation, the jailbreaker typically has complete control over the device’s workload and can reduce it to a minimum. This level of workload can also be expected on a standard local user’s machine, which is a common target by attackers for exploitation. Furthermore, in attacks on busy remote servers like web servers or cloud servers, attackers can monitor the server’s workload and strategically time their exploits during periods of lower activity, such as late at night.

In contrast, when operating within extremely stressed environments, it is expected that the success rates of Page Spray, as well as the other compared techniques, would experience a decrease. Nevertheless, Page Spray maintains a superior success rate in comparison to the Single-Thread Heap Spray method, and it delivers results comparable to those achieved with Multi-Process Heap Spray. Notably, in specific circumstances, Page Spray even performs on par or significantly better than Multi-Process Heap Spray, as exemplified by CVE-2017-10661, CVE-2017-15649, CVE-2018-6555, CVE-2017-8890, and CVE-2022-2588. The forthcoming subsection will delve into the conditions under which Page Spray excels and elucidate the rationale behind its performance.

In summary, the outcomes of both evaluations illustrate that Page Spray is a robust and effective approach that can serve as a valuable complement to conventional object spray methods. When used in the correct scenarios, these techniques cover each other’s limitations, leading to a broader range of vulnerabilities that can be exploited and ultimately enhancing the stability of successful exploits.

In order to explain and have a better understanding of the evaluation results and subsequent comparisons, it is imperative to first understand the key factor that influences the success rate of exploitation techniques and how they differentiate between Page Spray and conventional object spray approach. In the context of object spraying, in order to reclaim the vulnerable object’s slot, the object must be in the active slab. Consequently, the exploit program has to race against the unpredictable and random allocations coming from the busy kernel with the goal to reclaim that specific slot for the desired object.

In contrast, page spraying can mitigate this issue, by spraying the target cache with spray objects until the current slab is full, and another slab is allocated as the active slab, all before freeing the vulnerable object. In this case, all the unpredictable allocations from the kernel are directed into the active slab, while the freed vulnerable object resides in another slab, remaining untouched. This is possible because in this technique, the goal is not to reclaim the individual object, but rather to target the entire page for reclamation. However, it is worth noting that the stability concern in the context of page spraying arises during the actual spraying process itself. The key requirement for the pages to be recycled to the allocator is that all objects within the entire slab containing the vulnerable object must be freed. Consequently, there must be no unpredicted allocation within the same slab, as this would impede this requirement.

This characteristic is an advantage for Page Spray under certain conditions. For instance, in the case of CVE-2017-10661, Page Spray shows an remarkable advantage over traditional approach, boasting a success rate of 98.1% compared to the traditional method’s 78.3%. A similar trend is observed in CVE-2017-8890, where Page Spray achieves a success rate of 49.0% compared to the traditional approach’s 27.8%. We specifically examined these cases and it became evident that they have one important thing in common: the vulnerable objects are freed in RCU [42]. This means that the vulnerable objects undergo a grace period before they are returned to the allocator. Importantly, the duration of this grace period is not visible to the exploit program. Therefore, the common solution is to let the process sleep for a few seconds before attempting to reclaim the vulnerable object’s slot. As mentioned above, the race to reclaim this slot is the most critical source of instability for the traditional heap spraying approach. Therefore, the longer the process remains in the sleep state after the object has been freed, the lower the likelihood of successfully reclaiming it, thus explaining the low success rates observed. Page Spray does not suffer from this problem as the reclamation stage is not the critical source of its instability.

As we discussed earlier in §2.2, different GFP flags can influence the allocation zones in the Linux Kernel. One straightforward approach involves adjusting the GFP flags at the points where Page Spray is invoked, directing the allocation to a different memory area that does not overlap with the previous slab memory. Although some other GFP flags can be leveraged to achieve the isolation, to select appropriate flags, it’s essential to understand the allocation fallback mechanism. In scenarios where the memory areas best suited for the allocation flags are unavailable for upper-level components, the fallback mechanism is triggered to allocate in the next available zones. At the end of this fallback sequence, the DMA region cannot further fall back to another memory area.

Given that no specific ZONE is initially designated as a reserved isolation area for against Page Spray, we make adjustments to the allocation attributes within the Page Spray callsites in the Linux Kernel. We attach GFP_DMA to the Page Spray allocation points in kernel, which finally reclaims pages from DMA region, instead of general region. This redirection of allocation operations effectively separates Page Spray allocation from the freed slub pages and eliminates the overlapping. It’s important to emphasize that our aim here is to validate the feasibility of this principle, and it’s not intended for application in a production environment.

Slab Virtual, a mitigation technique designed by Google and currently maintained outside the Linux Source Code Tree, addresses concerns related to object reuse and cross-cache attacks. This approach extends prior work, such as AUTOSLAB [29] by Grsecurity and PartitionAlloc [6] by Chromium, by taking a more comprehensive approach. Originally, AUTOSLAB is not enough to mitigate Page Spray, since it only isolates objects at object level, page reuse can still happen if the attacker chooses the same type of object for padding objects and vulnerable object.

Conversely, Virtual-Slab operates by creating a new, dedicated virtual memory region (previously an unused hole in the address space). In this region, slab objects are allocated, isolating them from the regular memory allocation process. Additionally, adjustments are made to functions like virt_to_phys() to ensure that the mapping between virtual and physical slab memory becomes permanent. This step is crucial because it prevents the possibility of evading UAF attacks in the physical address space. By combining these measures, Virtual slab significantly reduces the potential for overlap between Page Spray allocations and freed slab pages. However, it introduces incompatibility (e.g. compilation and/or runtime conflicts with common defenses such as KFENCE and KASAN), and noticeable overhead compared to our direct mitigation. Furthermore, it is important to note that as of now, Virtual slab has not been integrated into the Linux Mainline, and therefore the current Linux kernel can still be exploited with Page Spray.

To assess the macro-performance impact of the aforementioned patches, we implemented both of them in Linux version 6.1. We conducted our experiments on a bare-metal machine equipped with 32GB of memory, a 200GB SSD storage drive, and a 4-core 11th Gen Intel i7 processor running at 2.90GHz. The performance evaluations were executed using Phoronix-Benchmarks [36]. For each specific benchmark case, we ran the tests five times and calculated the average results. The outcomes of our measurements are summarized in Table 4. Notably, the introduction of Virtual SLUB seems to result in an approximate 4% macro-overhead in these benchmarks. In contrast, the Hardened patch introduces minimal and practically negligible performance overhead.