DirtyCred: Escalating Privilege in Linux Kernel

Zhenpeng Lin Yuhang Wu Xinyu Xing

[email protected] [email protected] [email protected]
Northwestern University Northwestern University Northwestern University

ABSTRACT 1 INTRODUCTION
The kernel vulnerability DirtyPipe was reported to be present in Nowadays, Linux has become a popular target for cybercrooks
nearly all versions of Linux since 5.8. Using this vulnerability, a bad due to its popularity among mobile devices, cloud infrastructure,
actor could fulfill privilege escalation without triggering existing and Web servers. To secure Linux, kernel developers and security
kernel protection and exploit mitigation, making this vulnerabil- experts introduce a variety of kernel protection and exploit miti-
ity particularly disconcerting. However, the success of DirtyPipe gation techniques (e.g., KASLR [15] and CFI [20]), making kernel
exploitation heavily relies on this vulnerability’s capability (i.e., exploitation unprecedentedly difficult. To fulfill an exploitation goal
injecting data into the arbitrary file through Linux’s pipes). Such successfully, today’s bad actor has to identify those powerful ker-
an ability is rarely seen for other kernel vulnerabilities, making nel vulnerabilities with the capability of disabling corresponding
the defense relatively easy. As long as Linux users eliminate the protection and mitigation.
vulnerability, the system could be relatively secure. However, a recent vulnerability (cataloged as CVE-2022-0847 [11])
This work proposes a new exploitation method – DirtyCred – and its exploitation method are getting significant attention from
pushing other Linux kernel vulnerabilities to the level of DirtyP- the cybersecurity community. Because of its maliciousness and
ipe. Technically speaking, given a Linux kernel vulnerability, our impact, it was even branded a nickname – DirtyPipe [30]. Unlike
exploitation method swaps unprivileged and privileged kernel cre- non-branded kernel vulnerabilities, DirtyPipe’s exploitation fulfills
dentials and thus provides the vulnerability with the DirtyPipe-like privilege escalation without involving the effort of disabling broadly
exploitability. With this exploitability, a bad actor could obtain adopted kernel protection and exploit mitigation. This characteris-
the ability to escalate privilege and even escape the container. We tic results in existing Linux defenses ineffective and thus leads many
evaluated this exploitation approach on 24 real-world kernel vul- Linux-kernel-driven systems in danger (e.g., Android devices).
nerabilities in a fully-protected Linux system. We discovered that While DirtyPipe is powerful, its exploitability is closely tied to
DirtyCred could demonstrate exploitability on 16 vulnerabilities, the vulnerability’s capability (i.e., abusing the Linux kernel pipe
implying DirtyCred’s security severity. Following the exploitabil- mechanism to inject data to arbitrary files). For other Linux kernel
ity assessment, this work further proposes a new kernel defense vulnerabilities, such a pipe-abusive ability is rarely provided. As a
mechanism. Unlike existing Linux kernel defenses, our new defense result, the action taken by the Linux community and device manu-
isolates kernel credential objects on non-overlapping memory re- facturers (e.g., Google) is to release a patch against the kernel bug
gions based on their own privilege. Our experiment result shows rapidly and thus eliminate the attack surface. Without this attack
that the new defense introduces primarily negligible overhead. surface, the exploitation against a fully-protected Linux kernel is
still challenging. For other kernel vulnerabilities, it is still difficult
CCS CONCEPTS to bring the same level of security impact as DirtyPipe.
• Security and privacy → Operating systems security; Software In this work, we present a novel, general exploitation method
security engineering; through which even ordinary kernel vulnerabilities could fulfill the
same exploitation objective as DirtyPipe. From a technical perspec-
KEYWORDS tive, our exploitation method is different from DirtyPipe. It does
not rely on the pipeline mechanism of Linux nor the nature of the
OS Security; Kernel Exploitation; Privilege Escalation vulnerability CVE-2022-0847. Instead, it employs a heap memory
ACM Reference Format: corruption vulnerability to replace a low privileged kernel creden-
Zhenpeng Lin, Yuhang Wu, and Xinyu Xing. 2022. DirtyCred: Escalating tial object with a high privileged one. This practice confuses the
Privilege in Linux Kernel. In Proceedings of Proceedings of the 2022 ACM Linux kernel into thinking that an unprivileged user could gain
SIGSAC Conference on Computer and Communications Security, Los Angeles, permission to operate on high privileged files or processes. As such,
CA, USA., November 7–11, 2022 (CCS ’22), 14 pages. we name this exploitation method after DirtyCred.
https://doi.org/10.1145/3548606.3560585 To perform exploitation, DirtyCred confronts three critical tech-
nical challenges. First, it needs to pivot a vulnerability’s capability
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
to the one useful for credential object swap because vulnerabilities
for profit or commercial advantage and that copies bear this notice and the full citation in different types provide different capabilities in memory corrup-
on the first page. Copyrights for components of this work owned by others than ACM tion, which may not look sufficient for a credential object swap at
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specific permission and/or a first glance. Second, DirtyCred needs to control the time window
fee. Request permissions from [email protected]. to launch object swap strictly. As we will discuss in Section 3, the
CCS ’22, November 7–11, 2022, Los Angeles, CA, USA. time window valuable for DirtyCred is short. Without a practical
© 2022 Association for Computing Machinery.
ACM ISBN 978-1-4503-9450-5/22/11. . . $15.00
mechanism to extend the time window, the exploitation would be
https://doi.org/10.1145/3548606.3560585 unstable. Third, DirtyCred needs to find an effective mechanism

1963
CCS ’22, November 7–11, 2022, Los Angeles, CA, USA. Zhenpeng Lin, Yuhang Wu, and Xinyu Xing

that allows an unprivileged user to allocate privileged credentials prototype on Linux Kernel, showing it introduces negligible and
in an active fashion because failing to have this ability would make moderate performance overhead.
the credential object swap ineffectual. The rest of this paper is organized as follows. Section 2 intro-
To address the technical challenges above, we first introduce a duces the background needed for this research and discusses the
series of vulnerability pivoting schemes that allow us to convert any threat model. Section 3 introduces the high-level idea of DirtyCred
heap-based vulnerability into an ability to free credential objects and summarizes the technical challenges that DirtyCred confronts.
in an invalid manner. Second, we leverage three different kernel Section 4, 5, and 6 presents various techniques methods to handle
features – userfaultfd [37], FUSE [36], and lock in filesystem – to the technical challenges. Section 7 evaluates the effectiveness of
extend the time window needed for object swap and thus stabilize the proposed exploitation approach on real-world Linux kernel
exploitation. Last but not least, we employ various kernel mecha- vulnerabilities. Section 8 introduces a new defense mechanism and
nisms to spawn high privileged threads from both userspace and evaluates its performance on standard benchmarks. Section 9 pro-
kernel space and thus actively allocate privileged objects. In this vides the discussion of related work, followed by the discussion
work, we evaluate DirtyCred’s exploitability by using 24 real-world of some related issues and future work in Section 10. Finally, we
kernel vulnerabilities. We surprisingly discovered that DirtyCred conclude the work in Section 11.
could demonstrate privilege escalation on 16 vulnerabilities and con-
tainer escape. We shared our newly proposed exploitation method 2 BACKGROUND & THREAT MODEL
with Google Vulnerability Rewards Program (kCTF VRP [21]) and
received their acknowledgment and $20,000 bounty reward. This section introduces some technical background necessary for
With the strong exploitability demonstration and the lack of understanding our newly proposed exploitation method. Besides,
effective defenses, we believe that DirtyCred could soon become we discuss our threat model and assumptions.
a severe threat to Linux if the community does not take immedi-
ate action to explore and deploy a new defense mechanism. As a 2.1 Credentials in Linux kernel
result, following our new exploitation approach, we further pro- As is defined in [26], credentials refer to some kernel properties
posed a new Linux kernel defense mechanism. The basic idea of that contain privilege information. Through these properties, the
this defense is to host high privileged and low privileged objects in Linux kernel could examine users’ access privileges. In the Linux
non-overlapping memory regions. In this work, we do it by utilizing kernel, credentials are implemented as kernel objects which carry
the vmalloc region to store high privileged objects and the normal privilege information. To the best of our knowledge, those objects
region for low privileged ones. We implemented this defense as a include “cred”, “file”, and “inode”. In this paper, we designed our
Linux kernel prototype and evaluated its performance using a stan- exploitation methods by using only “cred" and “file" objects. We
dard benchmark. We show that our defense primarily introduces excluded the “inode” object because it can only be allocated when
negligible overhead. For some operations involving file operations, a new file is created on the filesystem, which does not provide
it demonstrates only moderate performance overhead. sufficient flexibility for memory manipulation (a critical operation
Compared with existing kernel exploitation techniques, Drity- in a successful program exploitation). We provide some necessary
Cred has many unique characteristics. First, it is a general exploita- background for “cred”, “file”, and “inode”, objects in the following.
tion approach because it enables privilege escalation for arbitrary Every Linux task contains a pointer referencing a ‘cred’ object.
heap-based vulnerabilities. Second, it could significantly unload The ‘cred’ object contains the UID field, indicating the task privilege.
the burden of exploit migration because – following DirtyCred – For example, GLOBAL_ROOT_UID indicates the task has the root privilege.
one could craft an exploit that can transfer from one kernel ver- When a task attempts to access a resource (e.g., a file), the kernel
sion or architecture to another without any modification. Third, it checks the UID in the task’s ‘cred’ object, determining whether the
could bypass many powerful kernel protection and exploit mitiga- access could be granted. In addition to UID, the ‘cred’ object also
tion mechanisms (e.g., CFI [16], KASLR [15], SMEP/SMAP [8, 29], contains capability. The capability specifies the task’s fine-grained
KPTI [9], etc.). Last, it could go beyond privilege escalation, leading privilege. For example, CAP_NET_BIND_SERVICE indicates the task could
to more severe security problems, such as rooting Android and bind a socket to an internet domain privileged port. For each task,
escaping a container. their credential is configurable. When altering the task credential,
In summary, this paper makes the following contributions. the kernel follows the copy-and-replace principle. It first copies the
credential. Second, it modifies the copy. Finally, it changes that cred
pointer in the task to the newly modified copy. In Linux, each task
• We propose a new, general exploitation method – DirtyCred
may alter only its own credentials.
– that could circumvent widely adopted kernel protections and
In the Linux kernel, every file comes with its owner’s UID and
exploit mitigation and thus fulfill privilege escalation in the Linux
GID, other users’ access permission, and capability. For executable
system.
files, they also have SUID/SGID flags indicating special permission
• We demonstrate that DirtyCred could manifest strong exploitabil-
that allows other users to run with the owner’s privileges. In the
ity on many real-world Linux kernel vulnerabilities. We also show
Linux kernel implementation, each file is tied to an ‘inode’ object
that the exploitable objects useful for DirtyCred are diverse and
linking to the credentials. When a task attempts to open a file, the
abundant.
kernel invokes function inode_permision, checking the inode and the
• We analyze existing kernel defenses’ limitations and propose
corresponding permission before granting the file access. After a file
a new defense mechanism. We implemented this defense as a
is opened, the kernel delinks the credentials from the ‘inode’ object

1964
DirtyCred: Escalating Privilege in Linux Kernel CCS ’22, November 7–11, 2022, Los Angeles, CA, USA.

file object for /tmp/x fs_context freed file object for /etc/passwd
/tmp/x object object /etc/passwd

Step 1: allocate a writable Step 2: free the file object Step 3: allocate privileged file
file object. through the vulnerability. object to reclaim the freed slot. After attack
Timeline
Content of /etc/passwd:
filp_cache /tmp/x filp_cache filp_cache /etc/passwd
hacker:x:0:0:root:/:/
source source source bin/sh
root:x:0:0:root:/root:/
kmalloc-192 kmalloc-192
bin/bash
kmalloc-192
daemon:x:1:1:daemon:/
usr/sbin:/usr/sbin/
nologin
fs_context fs_context fs_context …

Open file /tmp/x Write “hacker:x:0:0:root:/:/bin/sh” to the opened file

Figure 1: The overview of exploiting CVE-2021-4154, the write operation to the opened file starts between step 1 and step 2 and finishes after step 3.

and attaches them to the ‘file’ object. In addition to maintaining performance. Allocations that fall into dedicated caches do not
the credentials, the ‘file’ object also contains the file’s read/write share the same memory page with general allocations. As a result,
permission. Through the ‘file’ object, the kernel could index to the objects allocated in the generic cache are not adjacent to objects in
cred object and thus examine the privilege. Besides, it could check dedicated caches. It could be viewed as cache-level isolation, which
read/write permission and thus ensure that a task does not write mitigates the overflow threat from objects in general caches.
data to a file opened in a read-only mode.
2.3 Threat Model
2.2 Kernel Heap Memory Management In our threat model, we assume an unprivileged user has local access
Linux kernel designs memory allocators to manage small memory to the Linux system, aiming to exploit a heap memory corruption
allocation to improve performance and prevent fragmentation. Al- vulnerability in the kernel and thus escalate his/her privilege. Be-
though there are three different memory allocators in the Linux sides, we assume that Linux enables all the exploit mitigation and
kernel, they follow the same high-level design. To be specific, they kernel protection mechanisms available in the upstream kernel
all use caches to maintain the same size memory. For each cache, (version 5.15). These mechanisms include KASLR, SMAP, SMEP,
the kernel allocates memory pages and divides the memory into CFI [8, 15, 16, 29], KPTI [9], etc. With these mitigation and protec-
multiple pieces of the same size, and each piece is a memory slot tions, the kernel address is randomized, the kernel cannot access
used for hosting an object. When the memory page for a cache is user-space memory directly during execution, and its control-flow
exhausted, the kernel allocates new pages for the cache. If a cache integrity is guaranteed. Last but not least, we do not assume there
no longer uses the memory page, i.e., all the objects on the memory is a hardware side channel that could facilitate kernel exploitation.
page are freed, the kernel recycles the memory page accordingly.
There are two main kinds of caches in the Linux kernel, as is briefly 3 TECHNICAL OVERVIEW & CHALLENGES
described below. In this section, we first introduce the high-level idea of DirtyCred
Generic Caches. Linux kernel has different generic caches to al- by using a real-world example. Then, we analyze and discuss the
locate different-sized memory. When allocating memory from the technical challenges that DirtyCred needs to address.
generic caches, the kernel will first round up the requested size
and find the cache matching the size request. Then, it allocates a 3.1 Overview
memory slot from the corresponding cache. In the Linux kernel,
We take a real-world Linux kernel vulnerability (CVE-2021-4154 [10])
if an allocation request does not specify which kinds of caches it
as an example showcasing how DirtyCred works at a high level.
allocates from, the allocation by default occurs at generic caches.
CVE-2021-4154 is due to a type confusion error that a file object is
For allocations that fall into the same generic cache, they may share
referenced by the source field of fs_context object incorrectly. In the
the same memory address as they may be maintained on the same
Linux kernel, the lifetime of a file object is maintained through ref-
memory page.
erence count mechanism. The file object will be free automatically
Dedicated Caches. Linux kernel creates dedicated caches for per- when the reference count becomes zero, meaning that the file object
formance and security purposes. As some objects are used fre- is no longer being used. However, by triggering the vulnerability,
quently in the kernel, dedicating caches for these objects could the kernel will free the file object invalidly even if the file is still in
reduce the time spent on their allocation and thus improve system use.

1965
CCS ’22, November 7–11, 2022, Los Angeles, CA, USA. Zhenpeng Lin, Yuhang Wu, and Xinyu Xing

As is depicted in Figure 1, DirtyCred first opens a writable file Credential Victim Vulnerable
object object object
“/tmp/x”, which will allocate a writable file object in kernel. By
triggering the vulnerability, the source pointer will reference the
file object in the corresponding cache. Then, DirtyCred attempts 0xf…c20000 0xf…c20000
to write content to the opened file “/tmp/x”. Prior to the actual
content write, the Linux kernel checks whether the current file has ptr
permission to write and whether the position is writable, etc. After
passing the check, DirtyCred holds on to this actual file writing overflow
action and enters the second step. In this step, DirtyCred triggers
… ptr … 0xf…c20000
the free site of the fs_context object to deallocate the file object, which 0xf…c21f00
0xf…c21f00

leaves the file object as a freed memory spot.

Then, in the third step, DirtyCred opens a read-only file “/etc/-
passwd”, which triggers the kernel to allocate the file object for
“/etc/passwd”. As is illustrated in Figure 1, the newly allocated file ob-
(a) Memory layout before the overflow. (b) Memory layout after the overflow.
ject takes over the freed spot. After this setup, DirtyCred will release
its on-hold write action, and the kernel will perform the actual con-
tent writing. Since the file object has been swapped, the content on Figure 2: The memory layout before and after converting a heap overflow
hold will be redirected to the read-only file “/etc/passwd”. Assuming capability into the ability to deallocate a credential object.
that content written to “/etc/password” is “hacker:x:0:0:root:/:/bin/sh”,
a bad actor could use this scheme to inject a privileged account and
thus fulfill privilege escalation. how to pivot capability for different types of kernel vulnerabili-
The example above is just a demonstration indicating how Dirty- ties.
Cred uses file objects for exploitation. As is mentioned in Section 2, • As described in the example above, DirtyCred needs to hold
in addition to “file” objects, “cred” objects are also considered cre- on to the actual file writing after completing the permission
dential objects. Like the file swap showcased above, a bad actor can check and prior to the file object swap. However, holding on
also use a similar idea to swap cred objects and thus fulfill privilege to the actual writing is challenging. In the Linux kernel, the
escalation. Due to the space limit, we do not elaborate. Readers permission check and the actual content writing happen back-to-
interested in cred object exploitation could refer to our exploitation back quickly. Without a practical scheme to accurately control
demo published at [3]. the occurrence of file object swap, the exploitation would be
From the real-world example described above, we can observe inevitably unstable. In Section 5, we introduce a series of effective
that DirtyCred does not alter the control flow but exploits kernel mechanisms that guarantee the file object swap could occur at
memory management’s nature to manipulate objects in the memory. the desired time window.
As a result, many existing defenses that prevent control flow tam- • As is discussed above, one of the most critical steps in DirtyCred
pering do not affect DirtyCred’s exploitation. While some recent is to use a high-privilege credentials to replace the low-privilege
research works enable kernel defense by re-designing the memory one. To do that, DirtyCred allocates high-privileged objects, tak-
management (e.g. AUTOSLAB [34]), they are also ineffective in ing over the freed memory spot. However, it is challenging for a
blocking DirtyCred. As we will discuss in Section 8, the newly pro- low-privilege user to allocate high-privileged credentials. While
posed memory management methods are still in coarse-granularity, simply waiting for the activities from privileged users may po-
not sufficient for hindering our memory manipulation. tentially resolve the problem, such a passive strategy greatly in-
fluences exploitation stability. First, DirtyCred has no clue when
the desired memory spot could be reclaimed and thus continues
3.2 Technical Challenges its consecutive exploitation. Second, DirtyCred has no control
While the example above illustrates how DirtyCred performs ex- over the newly allocated objects. Therefore, it is possible that the
ploitation and thus fulfills privilege escalation, there are still many object that takes over the desired memory slot does not have the
technical details that need to be further clarified and many technical expected privilege level. In Section 6, we introduce a userspace
challenges that need to be tackled. mechanism and a kernel space scheme to address this problem.

• As is mentioned above, DirtyCred needs an invalid-free capabil-

ity to deallocate a low-privileged object (e.g., a file object with 4 PIVOTING VULNERABILITY CAPABILITY
write permission) and then reallocate a high-privileged one (e.g., As is demonstrated in the example depicted in Figure 1, the kernel
a file object with read-only permission). In practice, a kernel vulnerability cataloged as CVE-2021-4154 provides DirtyCred with
vulnerability may not always provide us with such a capabil- the ability to deallocate the file object in an invalid fashion. However,
ity. For example, a vulnerability may provide only out-of-bound in practice, a vulnerability may not demonstrate such a capability.
overwriting capability instead of an invalid-free directly against For example, a double-free (DF) or use-after-free (UAF) capability
a credential object. Therefore, DirtyCred needs corresponding may not directly tie to a credential object. Some vulnerabilities, like
approaches to pivot vulnerability’s capability for vulnerabilities out-of-bound (OOB) access, do not have invalid free capability. To
with different capabilities. In Section 4, we, therefore, describe this end, DirtyCred needs to pivot a vulnerability’s capability. In

1966
DirtyCred: Escalating Privilege in Linux Kernel CCS ’22, November 7–11, 2022, Los Angeles, CA, USA.

Credential
the following, we describe how we design DirtyCred for capability Allocated Vulnerable Freed Credential object being
object object memory object
pivot. attacked
ptr 1 ptr 2 ptr 2

4.1 Pivoting OOB & UAF Write

Given an OOB vulnerability or a UAF vulnerability with the ca-
(a) Allocate a vulnerable object. (b) Free the vulnerable object through ptr 1.
pability of overwriting data in a cache, DirtyCred first identifies ptr 1’ ptr 2’ ptr 2 ptr 1’ ptr 2’
an object (i.e., victim object) that shares the same cache and en-
closes a pointer referencing a credential object. Then, it utilizes
heap manipulation techniques [7, 48] to allocate the object at the
(c) Reclaim the freed slot with another (d) Free the vulnerable object through ptr 2.
memory region where the overwriting happens. As shown in Fig- vulnerable object.
ure 2 (a), to pivot an OOB vulnerability, the victim object is just ptr 1’ ptr 2’ ptr 1’ ptr 2’

right after the vulnerable object. Using the overwriting capabil-

ity, DirtyCred further modifies the object-enclosed pointer. More
specifically, DirtyCred uses the overwriting capability to write zero (e) Destroy the memory cache. (f) Reclaim the memory page with credential
object.
to the last two bytes of the pointer referencing the credential object ptr 1’ ptr 1’

(see Figure 2 (b)).

Recall that a cache is organized on contiguous pages. In the
Linux kernel, the address of a memory page is always in a format (h) Reclaim the freed slot with a credential
(g) Trigger the free through ptr 2’.
where the last byte is zero. When allocating objects in a new cache, object.

the object starts from the beginning of the memory page. As a

result, the zero-byte overwriting above would force the pointer Figure 3: The step-by-step example demonstrating converting a double-
to reference the beginning of a memory page. For example, as is free capability into the ability to deallocate a credential object.
illustrated in Figure 2 (b), after nullifying the last two bytes of the
pointer referencing a credential object, the pointer references to 1 struct iovec
2 {
the beginning of a memory page in which another credential object 3 void __user *iov_base; /* BSD uses caddr_t (1003.1g requires
resides. ↩→ void *) */
As is shown in Figure 2 (b), after the pointer manipulation, Dirty- 4 __kernel_size_t iov_len; /* Must be size_t (1003.1g) */
5 };
Cred obtains an additional reference to the first object of the mem- 6
ory page. We argue that this additional object reference means 7 ssize_t vfs_writev(...)
success in capability pivot. The reason is that kernel could free 8 {
9 // permission checks
the object normally, leaving the pointer in the victim object as a 10 if (!(file->f_mode & FMODE_WRITE))
dangling pointer. Then, following the similar procedure described 11 return -EBADF;
in Section 3, DirtyCred could perform a heap spray, occupy that 12 if (!(file->f_mode & FMODE_CAN_WRITE))
13 return -EINVAL;
freed spot with a high-privileged credential object, and thus fulfill 14
privilege escalation. 15 ...
16 // import iovec to kernel, where kernel would be paused
17 // using userfaultfd & FUSE
4.2 Pivoting DF 18 res = import_iovec(type, uvector, nr_segs,
19 ARRAY_SIZE(iovstack), &iov, &iter);
In the Linux kernel, general caches (e.g., kmalloc-96) and dedicated 20 ...
caches (e.g., cred_jar) are isolated. The objects enclosed in these 21 // do file writev
22 }
caches have no overlap. However, the Linux kernel has a recycling
mechanism. When destroying a memory cache, it recycles the cor-
responding unused memory pages and then assigns the recycled Listing 1: The code snippet of vfs_writev function in kernel before 4.13.
pages to the caches that need more space. This characteristic en-
ables cross-cache memory manipulation, providing DirtyCred with leaving the second pointer behind (see Figure 3 (b)). Then, it re-
the ability to pivot capability for double-free vulnerabilities. allocates the vulnerable object, taking over the freed memory spot.
Figure 3 shows the procedure of how DirtyCred converts a As is shown in Figure 3 (c), after the reallocation, there are three
double-free capability to the capability needed for privileged object pointers referencing the vulnerable object. One is the pointer left
swap. First, DirtyCred allocates many objects in the cache where the behind by the first vulnerable object. The other two are those tied
vulnerability occurs. Among these newly allocated objects, there is to the double-free capability against the newly allocated vulnerable
a vulnerable object. Using two different pointers, DirtyCred could object.
deallocate the vulnerable object twice in an invalid fashion. Since Using one of the three-pointers referencing the vulnerable object,
the number of allocations is large, DirtyCred could ensure that a DirtyCred further deallocates the newly allocated vulnerable object,
cache is full of newly allocated objects after the massive object leaving a freed memory spot referenced by two dangling pointers
allocation (see Figure 3 (a)). (see Figure 3 (d)). As mentioned above, the Linux kernel recycles the
Following the massive allocation, DirtyCred utilizes the first memory page and assigns it to another cache if a cache contains no
pointer to deallocate the vulnerable object in an invalid fashion, allocated objects. Therefore, after the deallocation of the vulnerable

1967
CCS ’22, November 7–11, 2022, Los Angeles, CA, USA. Zhenpeng Lin, Yuhang Wu, and Xinyu Xing

object, DirtyCred further deallocates other objects in the cache and 1 ssize_t vfs_writev(...)
2 {
thus frees up the cache accordingly (see Figure 3 (e)). 3 ...
On the recycled memory page, the kernel creates a new cache 4 // import iovec to kernel, where kernel would be paused
that stores credential objects. The new cache divides the page mem- 5 // using userfaultfd
6 res = import_iovec(type, uvector, nr_segs,
ory into slots. As is depicted in Figure 3 (f), if the size of the vulnera- 7 ARRAY_SIZE(iovstack), &iov, &iter);
ble object is different from that of the credential object, the address 8 ...
9 // permission checks
of the credential object will not align with that of the vulnerable 10 if (!(file->f_mode & FMODE_WRITE))
object, making the two remaining pointers reference the middle 11 return -EBADF;
of the credential object. In this memory status, DirtyCred cannot 12 if (!(file->f_mode & FMODE_CAN_WRITE))
13 return -EINVAL;
follow the exploitation procedure described in Section 3 because the 14 ...
success of exploitation requires the ability to deallocate a credential 15 // do file writev
object. 16 }
To address this problem, DirtyCred first uses one of the remain-
ing pointers to deallocate the credential object in the middle. As is Listing 2: The code snippet of vfs_writev function in kernel after 4.13.
illustrated in Figure 3 (g), after this deallocation, the kernel creates
a freed memory spot. This freed spot is the size as same as a creden-
tial object. Therefore, when DirtyCred allocates a new credential In this work, DirtyCred utilizes these features to pause kernel
object, the kernel fills that freed spot with the new credential object. execution after the file permission check is completed. In the follow-
As we can observe in Figure 3 (h), after the freed spot is taken over, ing, we take userfaultfd as an example to describe how DirtyCred
the last remaining pointer references the newly allocated credential fulfills the kernel pause and extends the exploitation time window.
object. It implies the success of the capability pivot. The reason is For FUSE, the kernel pause procedure is similar. Readers could refer
that DirtyCred could utilize the remaining pointer to deallocate the to the exploit sample we developed [3].
credential object in an invalid fashion and then perform an object When performing file write, DirtyCred invokes syscall writev, the
swap for privilege escalation. implementation of vectored I/O. Unlike syscall write, this syscall
uses structure iovec to pass data from userspace to kernel space.
List 1 in Line 1∼5 defines the structure iovec. As we can observe, it
5 EXTENDING TIME WINDOW contains a userspace address and a size field indicating the amount
Recall that the Linux kernel needs to check file permission before of data that will be transferred. In the Linux kernel space, in order
performing a file write operation. DirtyCred needs to perform a to copy the data enclosed in iovec, the kernel needs to first import
file object swap between the permission check and the actual file the iovec to the kernel space. Therefore, before Linux kernel version
writing. However, this window is too short to perform a successful v4.13, as is shown in List 1, the implementation of writev first checks
exploitation since the swapping need to trigger the vulnerability the file object, ensuring that the current file is in open status and
and do heap layout manipulation, which might take a few seconds. with write permission. Once the check passes, it then imports the
To address this problem, DirtyCred utilizes several techniques to iovec from userspace and writes user data to the corresponding

extend this time window to ensure it is larger than the time spent file. In this implementation, the import of iovec is in between the
for the swapping process. Here, we describe these techniques and permission check and data write. DirtyCred can simply utilize the
discuss how they could facilitate exploitation. aforementioned userfaultfd feature to pause kernel execution right
after completing the permission check and thus win sufficient time
to swap the file object. To the best of our knowledge, this technique
5.1 Exploitation of Userfaultfd & FUSE was firstly used by Jann Horn’s exploitation for CVE-2016-4557 [25],
Userfaultfd [37] and FUSE [36] are two critical features in the Linux but it is no longer available after kernel v4.13.
kernel. The userfaultfd feature allows userspace to handle page
faults. When a page fault is triggered on the memory registered in 5.2 Alternative Exploitation of Userfaultfd &
userfaultfd, the user registered page fault handler will get notified FUSE
to handle the page fault. Unlike userfaultfd, FUSE is a userspace After Linux kernel version v4.13, the kernel implementation gets
filesystem framework, allowing users to implement the userspace changed. The import of iovec was moved ahead of permission check
filesystem. Users could register their handler for the implemented (see List 2). In this new implementation, DirtyCred could still use
userspace filesystem to specify how to respond to file operating the userfaultfd feature to pause kernel execution at the site of iovec
requests. Both userfaultfd and FUSE could be utilized to pause import. However, it no longer gives DirtyCred the ability to extend
Linux kernel execution as long as the user want. For userfaultfd, an the time window between permission check and actual file write.
adversary could register a page fault handler for a memory page. To address this problem, DirtyCred exploits the design of the Linux
When the kernel attempts to access that memory and triggers a page filesystem.
fault, the registered handler will be invoked, allowing the adversary In Linux, the filesystem design follows a strict hierarchy in which
to pause kernel execution. For FUSE, an adversary could allocate the the high-level interface is common for file write operations, whereas
memory from the userspace filesystem. When the kernel accesses the low-level interface varies across filesystems. When writing a
this memory, it invokes the pre-defined file access handler and thus file, the kernel first invokes the high-level interface. As is shown
pauses kernel execution. in List 3, generic_perform_write is a high-level interface for file write

1968
DirtyCred: Escalating Privilege in Linux Kernel CCS ’22, November 7–11, 2022, Los Angeles, CA, USA.

1 ssize_t generic_perform_write(struct file *file, its filesystem enforces this practice by using a lock mechanism. To
2 struct iov_iter *i, loff_t pos)
3 { illustrate this, List 4 shows a simplified code snippet that performs
4 /* a write operation in the ext4 filesystem. As we can observe, the
5 * Bring in the user page that we will copy from _first_. filesystem first tries to obtain the inode lock in Line 6. If the inode
6 * Otherwise there's a nasty deadlock on copying from the
7 * same page as we're writing to, without it being marked is under the operation of another file (i.e., others hold the lock), the
8 * up-to-date. filesystem will wait until the lock is released. After obtaining the
9 */
10 if (unlikely(iov_iter_fault_in_readable(i, bytes))) {
lock, the filesystem calls generic_perform_write to write the data to the
11 status = -EFAULT; file. When it completes the write, the filesystem will release the
12 break; lock and return from the function.
13 }
14 ... The lock mechanism above could ensure the write operation does
15 // call the write operation of the file system not go wrong. Unfortunately, it leaves an opportunity for DirtyCred
16 status = a_ops->write_begin(file, mapping, pos, bytes, flags, to extend the time window and thus perform an object swap. To
17 &page, &fsdata);
18 ... be specific, DirtyCred could spawn two processes – process A
19 } and process B – to write data on the same file simultaneously.
Assume that process A holds the lock, writing a massive amount
Listing 3: The code snippet of generic_perform_write function in the of data. When process A writes the file, process B would have to
Linux kernel. wait for an extended period until the lock is released in Line 10.
Since prior to the invocation of generic_perform_write, process B has
1 static ssize_t ext4_buffered_write_iter(struct kiocb *iocb, already completed the file permission check, the time spent on lock
2 struct iov_iter *from) waiting provides DirtyCred with a sufficiently large time window
3 {
4 ssize_t ret; to complete file object swap without worrying about the block
5 struct inode *inode = file_inode(iocb->ki_filp); of permission check. Based on our observation, the hold-on time
6 inode_lock(inode); could elapse to dozens of seconds when writing a 4GB file to a hard
7 ...
8 ret = generic_perform_write(iocb->ki_filp, from, disk drive. Within this time window, triggering the vulnerability
↩→ iocb->ki_pos); and performing memory manipulation could be completed without
9 ... incurring any instability issue in exploitation.
10 inode_unlock(inode);
11 return ret;
12 }
6 ALLOCATING PRIVILEGED OBJECT
Listing 4: The code snippet of ext4 filesystem in the Linux kernel. As is mentioned in Section 3.2, DirtyCred cannot passively wait
for privileged users’ activities and expect that these activities could
result in a privileged object taking over the desired freed spot and
operation. As we can observe, in Line 15∼17, generic_perform_write thus fulfill privilege escalation. Therefore, DirtyCred has to take
invokes the write operation of the filesystem and writes data to the active action to trigger a privileged object allocation in the kernel
file. To guarantee performance and compatibility, just before the space. This section discusses how DirtyCred – running as a low-
write operation, the kernel triggers a page fault for the userspace privileged user – performs privileged object allocation.
data enclosed in iovec. As a result, using the userfaultfd feature in
Line 10, DirtyCred could pause kernel execution prior to actual file
writing and thus obtain a sufficient time window for privileged file 6.1 Allocation from Userspace
object swap. In the Linux kernel, the “cred” objects represent the privilege level
Compared with pausing kernel execution at the site of iovec im- of corresponding kernel tasks. The root user has a privileged cred
port, we argue that exploiting the filesystem’s design is more chal- object, representing the highest privilege. Therefore, if DirtyCred
lenging to mitigate. First, as is described in the Linux code comment, can actively trigger a root user’s activities, the kernel could allocate
removing page fault in iovec could potentially cause a deadlock issue the privileged cred objects accordingly. In Linux, when a binary
(see List 3). Some filesystems will inevitably encounter trouble if has SUID permission, it could be executed as if it is executed by the
the page is not pre-faulted. Second, while moving the page fault owner, regardless of whoever executes the binary. Using this char-
prior to the permission check could potentially resolve the problem, acteristic, a low-privileged user could spawn a root process when
this straightforward defense reaction scarifies kernel performance he/she executes a root-user-owned binary with a SUID permission
and, more importantly, suffers from potential circumvention. For set.
example, DirtyCred could remove the page right after triggering In the past, attackers focused on exploiting a vulnerability in a
the first-page fault. In this way, the kernel inevitably triggers the privileged binary and thus fulfilled privilege escalation. In this work,
page fault again and thus pauses the kernel execution right after DirtyCred does not rely on the vulnerabilities residing in privileged
the permission check. binaries. Instead, it abuses the aforementioned feature to spawn
SUID-set binaries owned by root users, allocating the privileged
5.3 Exploitation of Lock in Filesystem cred object to occupy the free memory spot. In Linux, the binaries
In order to avoid messing up the content of a file, a filesystem does that match the feature are many, including the executables such as
not allow two processes to write a file at the same time. In Linux, su, ping, sudo, mount, pkexec, etc.

1969
CCS ’22, November 7–11, 2022, Los Angeles, CA, USA. Zhenpeng Lin, Yuhang Wu, and Xinyu Xing

As discussed earlier, in addition to cred objects, DirtyCred also Memory Cache Structure Offset
could swap file objects for privilege escalation. Unlike cred objects, kmalloc-16 vdpa_map_file 0★
file object allocation is relatively easy. Recall that DirtyCred replaces binder_task_work_cb 16 ★
a write-permitted file’s object with a read-only file’s object when binder_txn_fd_fixup 16 ★
kmalloc-32
swapping file objects. To allocate file objects specifying read-only coda_file_info 8★
permission, DirtyCred could open multiple target files with only shm_file_data 16 ★
the read permission. In this way, the kernel would allocate many fuse_fs_context 8★
kmalloc-64 ovl_dir_file 24★ 32★
corresponding file objects in the corresponding kernel memory.
bpf_event_entry 8★
gntdev_dmabuf_priv 80 ★
nfs_access_entry 40 †
6.2 Allocation from Kernel Space kmalloc-96 request_key_auth 32 †
The method described above indicates a way that allocates privi- watch 64 †
leged objects from userspace. In fact, DirtyCred can also perform bpf_perf_link 64 ★
privileged object allocation from kernel space. When the Linux async 32 †
kmalloc-128
kernel starts a new kernel thread, it duplicates its current running nfs_delegation 16 †
fs_context 88 †
process. Together with the process duplication, the kernel allocates
sync_file 0★
a copied cred object on the kernel heap accordingly. In the Linux
vmci_ctx 144 †
kernel, most of the kernel threads have a privileged cred object. As coda_vm_ops 8★
a result, the copied cred object is also in high privilege. Using the kmalloc-192 nfs_open_context 80 †
ability to spawn privileged kernel threads, DirtyCred could actively nfs_unlinkdata 144 †
allocate privileged cred objects. nfs_renamedata 152 †
To the best of our knowledge, there are two major approaches nfs4_layoutreturn 144 †
to allocating high privileged credential objects. The first is to inter- ovl_fs 112 †
act with the kernel code snippets, triggering the kernel to spawn usb_dev_state 152 †
a privileged thread internally. For example, creating workers for autofs_sb_info 8★
kmalloc-256
kernel workqueue can also be used to spawn kernel threads. In the shmid_kernel 128 ★
bsd_acct_struct 144 ★
Linux kernel, the work queue is designed for handling deferred
linux_binprm 48 ★, 64 ★
functions. A work queue comes with a number of work pools. Each loop_device 96 ★
work pool contains workers. A worker is the underlying execution dma_buf 8★
unit that runs the work committed to the workqueue. The number nvmet_ns 24 ★
of the workers in each work pool is, at most, the number of the ksmbd_file 0★
kmalloc-512
CPUs. Initially, the kernel creates only one worker for each work rpc_clnt 440 ★
pool. When there is a need for more workers or, in other words, nfs4_state_owner 56 †
more works are committed to the work queue, the kernel will create nfs4_ff_layout_mirror 96 †, 104 †
workers dynamically. Each worker is a kernel thread. As a result, p9_trans_fd 0 ★, 8 ★
by adjusting the works committed to the kernel work queue, one sock 600 †
binder_proc 80 †
could control the activities of kernel thread spawning accordingly.
kfd_process_device 256 ★
In addition to the method above, the second approach to spawn- kmalloc-1k
send_ctx 0★
ing kernel threads is to invoke the usermode helper. Usermode nlm_host 520 †
helper is a mechanism that allows the kernel to create a user-mode nfs4_layoutcommit_data 472 †
process. One of the most straightforward applications of the user- vsock_sock 864 †
mode helper is loading kernel modules to kernel space. When load- kmalloc-2k
io_ring_ctx 408 †
ing a kernel module, the kernel calls the usermode-helper API, kmalloc-4k vduse_iova_domain 3824 ★
which further executes the userspace program – modprobe in high vm_area_cachep vm_area_struct 160 ★
privileged mode and thus creates a high privileged credential ob- ashmem_area_cache ashmem_area 288 ★
jects in the kernel. Part of modprobe functionality is to search client_slab nfs4_client 736 †
through the standard installed module directories to find the nec- nfsd_file_slab nfsd_file 48 ★, 56†
essary drivers. During the search, the kernel needs to continue its kioctx_cachep kioctx 512 ★
execution. As a result, to avoid modprobe blocking kernel execu-
Table 1: Exploitable objects identified in the Linux kernel. Note that the
tion, when invoking a usermode-helper API, the kernel also spawns symbol ★ indicates an object tied to “file” credential whereas the symbol †
a new kernel thread. represents an object associated with “cred” object. The column “Memory
Cache” specifies the caches storing kernel objects. The column “Structure”
represents the exploitable objects’ types. The column “Offset” describes
7 EVALUATION where the credential object’s reference is located in the exploitable object.
In this section, we design two experiments to evaluate the ex- Note that some exploitable objects contain two credential-object references
(e.g., ovl_dir_file and linux_binprm).
ploitability of DirtyCred on real-world kernel vulnerabilities.

1970
DirtyCred: Escalating Privilege in Linux Kernel CCS ’22, November 7–11, 2022, Los Angeles, CA, USA.

CVE-ID Observed Capability DirtyCred on the kernel heap. Due to the space limit, we detail the design and
CVE-2022-27666 OOB ✔ implementation of our automated method in [1].
CVE-2022-25636 Double Free ★ ✔ In addition to identifying exploitable kernel objects, our exper-
CVE-2022-24122 UAF ✗ iment also explores DirtyCred’s exploitability against real-world
CVE-2022-0995 OOB ✔ vulnerabilities. Recall that DirtyCred needs to pivot a vulnerability
CVE-2022-0185 OOB ✔ capability if the vulnerability does not provide DirtyCred with the
CVE-2021-22600 Double Free ✔ ability to swap credential objects directly. As is discussed in Sec-
CVE-2021-4154 UAF ✔ tion 4.1, when performing vulnerability pivoting, DirtyCred might
CVE-2021-43267 OOB ✔ need to overwrite some critical data in the exploitable object. For
CVE-2021-41073 Double Free ★ ✔ different vulnerabilities, their overwriting capability could vary
CVE-2021-34866 OOB † ✗ significantly, further impacting the success of privilege escalation.
CVE-2021-33909 OOB † ✗ As a result, we evaluate DirtyCred’s effectiveness by using it to
CVE-2021-42008 OOB ✔ exploit many real-world vulnerabilities and studying how well it
CVE-2021-3492 Double Free ✔ could perform exploitation against these vulnerabilities.
CVE-2021-27365 OOB ✔ We assume a Linux kernel is armed with state-of-the-art exploit
CVE-2021-26708 Double Free ★ ✔ mitigation techniques available in kernel when performing the ex-
CVE-2021-23134 Double Free ★ ✔ ploitation. As a result, we need to select vulnerabilities identified in
CVE-2021-22555 Double Free ✔ the kernel developed in recent years. In our evaluation, we selected
CVE-2021-3490 OOB † ✗ only Linux kernel CVEs reported after 2019. In our CVE selection
CVE-2020-14386 OOB ✔ process, we filtered out those vulnerabilities that do not corrupt data
CVE-2020-16119 Double Free ★ ✔ on the kernel heap. Besides, we ruled out those vulnerabilities for
CVE-2020-27194 OOB † ✗ which we cannot reproduce the corresponding kernel panic. Last
CVE-2020-8835 OOB † ✗ but not least, we also eliminated those vulnerabilities, the trigger
CVE-2019-2215 UAF ✗ of which requires the installation of specific hardware. Following
CVE-2019-1566 UAF ✗ these CVE selection criteria, we obtained a data set with 24 unique
CVEs. In Table 2, we listed these CVEs’ IDs and the corresponding
Table 2: Exploitability demonstrated on real-world vulnerabilities. Note vulnerability types. As we can observe, our selected test cases cover
that some CVEs provide both use-after-free and double-free capabilities. nearly all types of vulnerabilities on the kernel heap.
Here, we categorize such vulnerabilities into double-free and mark them
with a ★ symbol. Note that the symbol † indicates the vulnerabilities that
could corrupt only data in virtual memory area.

7.2 Experiment Result

7.1 Experiment Design & Setup
As is mentioned above, DirtyCred utilizes exploitable objects (i.e., Exploitable objects. Table 1 shows the exploitable objects identi-
the ones that enclose credential objects) to perform memory ma- fied in each kernel cache. As we can observe, the exploitable objects
nipulation particularly for vulnerabilities like out-of-bound access cover nearly all the general caches except for kmalloc-8, which is
and use-after-free. This manipulation is one of the critical steps for rarely used in the Linux kernel. For most of memory caches, there
DirtyCred to fulfill privilege escalation. When performing mem- are more than one exploitable object potentially useful for Dirty-
ory manipulation, DirtyCred allocates the exploitable object to the Cred’s privilege escalation. In each exploitable object, the offset of
cache where the vulnerability locates. For different vulnerabilities, the field referencing a credential object is also present in Table 1.
they demonstrate memory corruption capability on different caches. As we can observe, the offsets for different exploitable objects vary.
Therefore, the success of DirtyCred highly depends on whether it It indicates that DirtyCred has a higher chance of finding a suitable
could successfully identify exploitable objects that could fit into object to match a vulnerability’s capability and perform successful
the corresponding cache. With this in mind, we first identify the exploitation. For example, if a vulnerability demonstrates the ca-
unique exploitable objects available for each cache. pability of overwriting 8 bytes to an adjacent object at its offset of
In order to point out the objects, one instinct reaction is to seek the 8-th byte, an exploitable object with the critical data at the 8-th
through the Linux kernel code manually, pinpoint those exploitable byte would greatly facilitate DirtyCred’s privilege escalation.
objects, and figure out the input that could trigger the correspond- From Table 1, we also discover 5 objects in 5 general caches. They
ing allocation. However, Linux kernel code space is large and so- enclose the reference to the credential object at the beginning of
phisticated, making code examination impractical. Therefore, to the objects. It implies that even if the attackers only obtain a very
address this problem, we introduce an automated method to track limited memory corruption capability (e.g., overwriting two bytes
down exploitable objects and the corresponding input to trigger of zero at the beginning of a victim object), they are still capable of
their allocation. In our evaluation, we apply the automated method leveraging the identified exploitable object to launch a DirtyCred
to the latest stable kernel (i.e., version 5.16.15 at the time of this attack. It should be noted that Table 1 also distinguishes exploitable
paper writing). We consider an object as an exploitable object only objects referencing cred and file using different symbols. As we will
if the automated method can find an object that encloses the cre- discuss in Section 10, a cred object could provide better support for
dential object and can demonstrate an input to allocate that object

1971
CCS ’22, November 7–11, 2022, Los Angeles, CA, USA. Zhenpeng Lin, Yuhang Wu, and Xinyu Xing

container escape. Therefore, adequate exploitable objects with cred Benchmark Vanilla Hardened Overhead
object linkage indicate more substantial support in docker escape. Phoronix
Exploitability. Table 2 shows the exploitability of DirtyCred across Apache (Reqs/s) 28603.29 29216.48 -2.14%
different vulnerabilities. As we can observe, DirtyCred successfully Sys-RAM (MB/s) 10320.08 10181.91 1.34%
demonstrates kernel defense bypassing and privilege escalation Sys-CPU (Events/s) 4778.41 4776.69 0.04%
on 16 out of 24 vulnerabilities when the underlying Linux kernel FFmpeg(s) 7.456 7.499 0.58%
enables all the exploit mitigation mechanisms discussed in Sec- OpenSSL (Byte/s) 1149941360 1150926390 -0.09%
tion 2.3. This observation implies that DirtyCred could be used as OpenSSL (Sign/s) 997.2 993.2 0.40%
a powerful, general exploitation method for kernel vulnerability PHPBench (Score) 571583 571037 0.09%
exploitation tasks. Of the 16 exploitation-successful test cases, 8 PyBench (ms) 1303 1311 0.61%
are out-of-bound or use-after-free vulnerabilities, and the other 8 GIMP (s) 12.357 12.347 -0.08%
are double-free. DirtyCred succeeds on all double-free test cases PostMark (TPS) 5034 5034 0%
as a double-free capability could always be pivoted to freeing a
LMBench
credential object invalidly.
The failure cases are primarily from out-of-bound and use-after- Context Switch (ms) 2.60 2.57 -1.15%
free. For OOB vulnerabilities, the failure cases demonstrated mem- UDP (ms) 9.2 9.26 0.65%
ory corruption in the virtual memory area. To use DirtyCred, we TCP (ms) 12.75 12.73 -0.16%
need to find kernel objects with credential information. These ob- 10k File Create (ms) 13.8 14.79 7.17%
jects are usually allocated at the kmalloc’ed memory region but 10k File Delete (ms) 6.35 6.62 4.25%
not virtual memory. As a result, DirtyCred fails to find necessary Mmap (ms) 80.23 81.91 2.09%
objects for a successful exploitation. We annotate these cases with Pipe (MB/s) 4125.3 4028.9 2.34%
a † symbol in Table 2. As we will discuss in Section 10, the failure AF Unix (MB/s) 8423.5 8396.7 0.32%
of exploiting those cases does not mean DirtyCred cannot exploit TCP (MB/s) 6767.4 6693.3 1.09%
vulnerabilities on virtual memory. The memory corruption capabil- File Reread (MB/s) 8380.43 8380.65 0%
ities on virtual memory could still be pivoted to capabilities useful Mmap Reread (MB/s) 15.7K 15.69K 0.06%
for DirtyCred if there are suitable exploitable objects or using other Mem Read (MB/s) 10.9K 10.9K 0%
capability pivoting techniques. Mem Write (MB/s) 10.76K 10.77K -0.09%
For the UAF failure case CVE-2022-24122, it does not demon-
Table 3: The performance evaluation results of the proposed defense on
strate the overwriting capability through the dangling pointer but two different benchmarks – Phoronix and LMBench.
manifests merely an over-reading ability. As is discussed in Sec-
tion 4, DirtyCred relies on either invalid write capability or invalid
free capability. The over-reading capability of CVE-2022-24122 lim-
its DirtyCred to perform a successful capability pivoting, thus fails etc.), none of the existing kernel defenses are effective to DirtyCred
the attack. For CVE-2019-2215 and CVE-2019-1566, they manifest for the following reasons.
the overwriting capability. However, the overwriting ability does First, DirtyCred does not violate any control-flow integrity, mak-
not happen in the critical field of exploitable objects. Without such ing the effort of safeguarding kernel control flow futile. Second,
a capability, DirtyCred cannot manipulate necessary fields in the DirtyCred does not rely on a single exploitation component for ex-
kernel objects to free a credential object, thus fails the attack. ploitation. As is shown in Section 7, valuable objects for exploitation
are spread across nearly all general caches. Therefore, defending
against DirtyCred by eliminating exploitable objects is nearly infea-
8 DEFENSE AGAINST DIRTYCRED sible. Third, DirtyCred fulfills its exploitation goal by placing a legit
credential object to an illegitimate memory spot but not tampering
Given the exploitability demonstrated in the section above, we
with a credential object’s content. This exploitation practice makes
argue that DirtyCred is a severe threat to the existing Linux sys-
existing credential integrity protection techniques (e.g., Samsung
tem. While the technique of abusing lock mechanism could be
Knox’s Real-time Kernel Protection [42]) less likely to be effective.
mitigated by reengineering the filesystem, it is still not enough
Last but not least, DirtyCred performs privilege escalation by swap-
to block DirtyCred as it could be launched from another path –
ping high and low privileged credential objects between each other.
swapping cred object. Therefore, an effective approach is to pre-
This exploitation method fails many kernel object isolation schemes
vent the swap of credentials with different privilege level. From one
(e.g., AUTOSLAB [34] and xMP [43]) because they separate critical
perspective, userspace heap defenses are not adequate for Dirty-
kernel objects in their own memory regions based on the type of
Cred. The kernel wants the memory allocation/free/access to be as
the objects but not their privilege.
fast as possible. Otherwise, it will slow down user space programs
To this end, we argue that one effective defense solution against
and the entire system. Therefore, the memory allocator in the ker-
DirtyCred would be to isolate high privileged and low privileged
nel is much simpler than that in userspace (e.g., ptmalloc). This
objects, forcing them not to share the same memory space. In this
fact makes userspace heap defenses not applicable to kernel space.
way, DirtyCred will no longer be able to overlap objects with dif-
From another viewpoint, even if the Linux kernel has introduced
ferent privileges for privilege escalation. To achieve the goal above,
many defense mechanisms (e.g., CFI, SMEP, SMAP, and KASLR,
a straightforward reaction is to create two different caches. One is

1972
DirtyCred: Escalating Privilege in Linux Kernel CCS ’22, November 7–11, 2022, Los Angeles, CA, USA.

used for high privileged object storage. The other is used to hold low the benchmark 10 times to avoid randomness and took the average
privileged objects. Since caches are naturally isolated, this design as the observed performance. For Phoronix Test Suite, we ran the
could ensure that objects with different privileges have no overlap. test with batch mode, which will run the test 50 times and output
However, as we discussed in Section 4.2, once a memory cache the average values.
is destroyed, the Linux’s buddy allocator recycles the underlying Table 3 shows our evaluation results. First, we can observe that
memory page. Therefore, DirtyCred could still launch its attack by our proposed method mostly introduces negligible performance
abusing this memory-page recycle feature. overhead, indicating that our defense is lightweight. Second, we
Design. With the analysis above in mind, we propose a practical can observe that there is some moderate performance decrease for
defense solution that creates a cache for high privileged objects in the test cases – “10k File Create” and “10k File Delete” – in the LM-
the virtual memory region and leaves the low privileged objects in Bench. As is shown in Table 3, our proposed defense introduces an
the normal memory area (i.e. direct-mapped memory region). The overhead of over 4%. The reason behind this performance decrease
virtual memory region refers to dynamic allocations of virtually is that file objects were allocated to virtual memory region through
vmalloc rather than the normal memory region through kmalloc. In
contiguous memory within the kernel. It resides in the memory area
defined by V MALLOC_START through to V MALLOC_END. Since it is separated comparison with kmalloc, vmalloc is relatively slow because virtual
from the direct-mapped memory region, the regions designated memory have to re-map the buffer space into a virtually contiguous
to high privileged and low privileged objects would never overlap range, whereas ‘kmalloc’ never re-maps.
even after the caches are destroyed and the underlying memory It should be noted that the file deletion involves a lower perfor-
pages are recycled. mance downgrade than file creation (4.25% vs. 7.17%). The reason
behind the difference is that the free of file object is done through
Implementation. In this work, we implemented our proposed RCU, which is executed asynchronously to the file deletion pro-
defense against DirtyCred on the Linux kernel v5.16.15. In our im- cess. While the moderate overhead may raise the concern of some
plementation, we manually modified the ways of allocating cred production systems, it dramatically improves the kernel protection
objects and file object in kernel. If the allocation is for privileged against DirtyCred. In this work, our primary objective is to raise the
ones, we allocate them using virtual memory. To be specific, when Linux community’s awareness but not to build a secure, efficient
allocating cred objects, we examine the privilege based on the UID of defense solution. We leave the exploration of the alternative defense
the object. If the UID matches GLOBAL_ROOT_UID, which means the alloca- solution as our future research effort. Last, it should also be noted
tion is for privileged cred objects, we use vmalloc as the allocator to that some cases demonstrated slight performance improvement
allocate virtual memory for the object. For file objects, we examines after we introduced defense to the Linux kernel. This is mainly
the file’s mode. If the file is opened with write permission, we will due to the noise of our experiment although we tried to minimize
allocate the file object with vmalloc accordingly. Our implementation the noise as much as we could by running the benchmark multiple
is available at [3]. times, and disabling CPU boost on a bare-metal machine.
Technical discussion. Our proposed defense protects the Linux
kernel by enforcing memory isolation for credential objects. As is
mentioned above, our implementation determines the privilege at 9 RELATED WORK
the time of object allocation. However, the privilege could be altered This work introduces a new kernel exploitation method and the
by changing the UID during runtime (e.g., changing a low privileged corresponding defense to mitigate the threat. As a result, the works
credential object to a high privileged one through ’setuid’ syscall). most relevant to ours include kernel exploitation and kernel ex-
When this occurs, our proposed defense above will encounter secu- ploitation mitigation. In the following, we summarize the works
rity issues because we perform object isolation only at the time of on these two topics and discuss how they differ from our proposed
allocation. To address this problem, we manually modify the way techniques.
of altering kernel credential objects in our implementation. Specifi- Kernel exploitation. The kernel exploitation techniques evolved
cally, if the kernel changes UID of a credential object to GLOBAL_ROOT_UID, with the development of kernel defense. Prior to the introduction
we will copy the high privileged credential object to the ‘vmalloc’ of Supervisor Mode Execution Prevention (SMEP) [29], the tech-
region rather than altering the original one. However, we think nique – ret2usr [32] – exploits the Linux kernel by pivoting kernel
some issues might be raised if the future kernel development does execution to the userland. After the broad deployment of SMEP in
not follow the same pattern. As a result, we leave the exploration Linux, this technique no longer works because SMEP prevents ker-
of alternative solutions as part of our future work. nel execution in the userspace. Following SMEP, Supervisor Mode
Performance Evaluation. To evaluate our defense mechanism’s Access Prevention (SMAP) [8] was further proposed to block direct
performance, we ran two benchmarks against the vanilla Linux userspace access, which further enhances the separation of the
kernel and our defense-enabled kernel on a bare-mental machine kernel and userspace’s access. To bypass the protection enforced
(with an Intel 4-Core CPU, 16GB RAM, and 1000GB HHD). Our by SMEP/SMAP, researchers proposed a series of new exploita-
benchmarks include a micro-benchmark from LMbench v3.0 [40] tion methods. For example, Kemerlis et al. proposed the ret2dir
and a macro-benchmark from Phoronix Test Suite [41]. The LM- technique [31] that enables an adversary to mirror userspace data
bench evaluates the latency and bandwidth of syscalls and system within the kernel address space. Wu et al. introduce KEPLER [47]
I/O, whereas the Phoronix Test Suite examines the performance of that utilizes a particular kernel code gadget to transform the PC
real-world applications on two Linux kernels. For LMbench, We ran control to stack overflow and thus enables a long ROP chain.

1973
CCS ’22, November 7–11, 2022, Los Angeles, CA, USA. Zhenpeng Lin, Yuhang Wu, and Xinyu Xing

To prevent ROP attacks against the Linux kernel, Linux intro- From the defense philosophy viewpoint, our defense mechanism
duces KASLR, which increases exploitation difficulty by random- is different from the works safeguarding kernel control-flow in-
izing the kernel memory address layout. However, following the tegrity. It is similar to the works that isolate critical kernel data.
adoption of this kernel defense, security experts then proposed However, our defense is entirely different from these works from
many practical methods [6, 17, 23, 28] to circumvent KASLR. For the technical perspective. Rather than isolating objects based on
example, using elastic objects in the kernel. Chen et al. proposed the types and sensitivity, our defense performs memory isolation
ELOISE [6] that could disclose sensitive kernel information after based on the privilege of kernel objects. As such, it is more effective
overwriting the length field of elastic objects. Gruss et al. proposed in defending against the threat of DirtyCred.
a hardware side-channel attack that leverages pre-fetch instructions
to bypass KASLR. Recently, some security experts even proposed
10 DISCUSSION & FUTURE WORK
to utilize vulnerabilities in processors to launch Meltdown [38] and
Spectre [33] attacks and thus bypass KASLR’s protection on Linux. In this section, we discuss some other issues we have not yet discuss
In addition to memory address space randomization, security re- and present our future effort.
searchers also proposed techniques to randomize the heap memory Escaping container. Going beyond privilege escalation on Linux,
layout in the Linux kernel [18, 46]. With the heap randomization DirtyCred can facilitate container escape passively and actively. As
enabled, the heap layout is no longer linear, which increases the mentioned earlier, DirtyCred performs exploitation by swapping
difficulty for adversaries in performing heap layout manipulation. either file objects or cred objects. Using file objects for exploitation,
However, following the success of heap layout randomization, Xu DirtyCred could overwrite a high privileged file. However, no file
et al. proposed a memory collision technique [48]. This technique in a container provides the privilege to switch the namespace. In
uses the memory reuse mechanism to exploit kernel use-after-free order to address this problem, a recent work [13] shows that an
vulnerabilities without being hindered by heap randomization. attacker could passively wait for the runC process and thus execute
Unlike the above exploitation techniques, aiming to the circum- root commands on the host by overwriting the process. Motivated
vention of some specific kernel protection and exploit mitigation by this idea, DirtyCred could use the file object swap mechanism
but not an ultimate exploitation goal (e.g., privilege escalation), our to overwrite the runC process and thus fulfill container escape.
work focuses on end-to-end exploitation without the headache of Unlike the method above, using cred objects to perform con-
bypassing broadly deployed kernel defenses. As such, our exploita- tainer escape does not need passive wait. To do so, DirtyCred could
tion method is more general and consequential. As we will discuss first trigger a Linux kernel vulnerability, swap cred objects, and
in Section 10, DirtyCred can even facilitate the ability to escape thus escalate the attacker’s privilege to SYS_ADMIN. With this SYS_ADMIN
containers and root Android devices. ↩→ privilege in hand, the attacker could then follow a previously
Kernel defense. In addition to the kernel defenses introduced to- proposed docker escape method [4] that mounts a cgroup and then
gether with the existing exploitation methods above, there are also utilizes the notify_no_release mechanism to execute the root command
many other kernel protection and exploit mitigation mechanisms. on the host system. To demonstrate DirtyCred’s ability to escape
These defenses are proposed by academia and industry, receiving the container, we provide a working exploit at [3]. Reviewers could
significant attention from the security community. Here, we briefly download the exploit and see more docker escape details.
introduced some recently proposed or mostly adopted in practice.
Rooting Android. In addition to container escape, DirtyCred is
To thwart side-channel attacks against the Linux kernel, Gruss
also capable of rooting Android. The Android kernel is developed
et al. proposed a strict kernel and userspace isolation mechanism –
based on the generic Linux kernel. In practice, the Android kernel
KAISER [22]. This mechanism could ensure that the hardware does
is more difficult to exploit compared to the generic kernel because
not hold any information about kernel addresses while running in
of the more strict access control and newly shipped defenses [20].
user mode. To improve KASLR, Linux kernel developers introduce
DirtyCred can root Android with two paths of attacks discussed
Function Granular Kernel Address Space Layout Randomization
in this paper. On the one hand, DirtyCred could swap the task
(FGKASLR [2]). By randomizing the layout down to a code function
credentials directly, which grants attackers privileged task creden-
level, FGKASLR makes the code-reuse attack more challenging. To
tials, thus root privilege. On the other hand, DirtyCred could first
hinder control-flow hijacking, researchers also proposed a variety
utilize its file manipulation capability to overwrite shared system
of defense mechanisms to enforce control-flow i ntegrity i n the
library, which allows a privilege escalation from the restrict sand-
Linux kernel [12, 16, 19, 49]. For example, Yoo et al. proposed to
box. Then, it could overwrite kernel modules with malicious code,
implement an in-kernel, control-flow integrity protection by using
fulfilling arbitrary read and write, and eventually disable SELinux
ARM’s Pointer Authentication [49].
on Android. We demonstrated DirtyCred’s capability of rooting
In addition to kernel control-flow protection above, there are also
Android with zero-day vulnerabilities. By the time of writing this
a series of defense techniques that focus on providing protection for
paper, we reported the vulnerabilities to Google and received their
critical kernel data [5, 14, 27, 39, 45]. For example, AUTOSLAB [34]
acknowledgement.
and xMP [43] are such kernel defenses. As we discussed in Section 8,
AUTOSLAB isolates different types of objects into different memory Cross version / architecture exploitation. When crafting an
caches, which reduces the objects useful for kernel heap memory exploit under the guidance of DirtyCred, one could expect the same
manipulation. xMP employs virtualization techniques to isolate exploit code could work across different kernel versions or archi-
sensitive data and thus prevents them from being tampered with tectures without any modification for the following reasons. First,
by unlawful actors. unlike other exploitation methods that need the leakage of kernel

1974
DirtyCred: Escalating Privilege in Linux Kernel CCS ’22, November 7–11, 2022, Los Angeles, CA, USA.

base address to bypass KASLR, DirtyCred does not need to handle consistency, transactional system calls, and sandbox filesystem.
KASLR. As a result, the exploitation code does not include any data Source code detection analyzes the source code of the target pro-
specific for kernel versions or underlying architectures. Second, gram. It is obvious that this kind of defense method could not be
many previous kernel exploitation methods (e.g., KEPLER [47]) applied to defending against our exploitation because there is no
heavily rely on ROP to escalate privilege. When migrating such identified source code pattern in DirtyCred. Postmortem detection
exploits to a different architecture, one needs to modify the ROP detects TOCTOU vulnerabilities after the attack is actually carried
chain and thus preserve its exploitability. DirtyCred does not use out. This kind of method needs happens-before analysis, which does
any architecture-specific data as discussed throughout the paper. not affect our exploitation. The reason is that we use unexpected
Therefore, once a piece of exploit code is developed for a vulnerabil- free operations, which could not be seen in the analysis process.
ity, the exploit could work on other vulnerable kernels, regardless System call interposition monitors the system call sequence and
of their versions and the underlying architectures. thus determines attacks. Our exploitation method does not use a
Other ways to pivot capability. In Section 4, we proposed some malicious system call sequence. As a result, system call interposition
techniques to pivot a memory corruption capability to the capa- would not block us either. Intra/inter-process memory consistency
bility useful for DirtyCred. In our evaluation, we found vulnera- protects the shared variables in multiple threads by recording the
bilities happened on virtual memory are harder to exploit with operations on the variables. Our exploitation applies unexpected
DirtyCred. The reason is that there are less exploitable objects on operations which could not be recorded. Transactional system calls
virtual memory, which limits pivoting capability from the original and sandbox filesystem target the race condition between file read
memory corruption to ones that are useful for DirtyCred. We argue and write. Our method does not require that condition.
that this does not mean vulnerabilities on virtual memory cannot
be exploited with DirtyCred. For example, CVE-2021-34866 pro-
vides an out-of-bound capability that demonstrates an overwrite 11 CONCLUSION
on vmalloc’ed memory. Using our pivoting approach, we cannot The Linux kernel has been armed with various protection and
pivot this capability to deallocate a credential object. However, a exploitation mitigation schemes, making kernel exploitation chal-
recent writeup [24] shows a sophisticated method that could con- lenging to succeed. To bypass kernel defenses, a bad actor has
vert this overwrite capability on vmalloc into an arbitrary read and to leverage a vulnerability with a solid capability to disable pro-
write and thus enable a double-free capability. As is discussed and tection and mitigation. In this work, we show a new exploitation
shown in Section 4.2, using a double-free capability, DirtyCred has method – DirtyCred. It can enable exploitation and defense cir-
a high chance of fulfilling its privilege escalation. In addition to cumvention without a vital requirement for kernel vulnerability.
pivoting vulnerability capability, a recent work [35] demonstrates Using DirtyCred, we demonstrate that a bad actor could employ
an approach to exploring the vulnerability’s different capability. nearly arbitrary heap-based kernel vulnerability to swap creden-
We argue that these methods are complementary to the DirtyCred tial objects. The credential swap could confuse the Linux kernel
attack, as is shown in Section 3.1, DirtyCred could still be launched into believing a high privileged file or task is in a low privileged
without pivoting capability. In this work, we leave the exploration mode. Thus, an unprivileged user could escalate his or her privi-
of other pivoting methods as part of our future research. lege for malicious purposes. With this discovery, we conclude that
DirtyCred sabotages the existing Linux defense architecture. If our
Stability. DirtyCred’s exploitation stability could be impacted by
security community does not take immediate action in response
two critical factors like all kernel exploitation methods. First, when
to this new exploitation method, the Linux-driven systems will
pivoting vulnerability capability, DirtyCred has to manipulate the
soon be in danger. Their users will suffer from significant personal
memory layout, taking over the target memory spot. At this mo-
loss. Following this conclusion, this work also proposed a privilege-
ment, the exploitation stability might vary if the memory layout
object isolation mechanism as a defense suggestion. In this work,
manipulation is affected b y s ystem a ctivities. S econd, w hen ex-
we implemented this defense mechanism as a Linux kernel proto-
ploiting a kernel vulnerability, the way to trigger the vulnerability
type and found it could secure Linux at a negligible and sometimes
could also greatly influence t he s tability o f t he exploitation. To
moderate cost. With this new discovery, we further conclude that
improve exploitation stability, a recent work [50] proposes a series
isolating memory based on object privilege might be necessary for
of methods to stabilize kernel exploitation. In this work, our goal
defending against the threat of DirtyCred. We have reported part of
is to assess the exploitability of DirtyCred in a real-world setting.
our research findings to software and hardware vendors that could
We conclude DirtyCred could exploit a vulnerability successfully
potentially be affected by DirtyCred and are actively working with
as long as it demonstrates exploitability. In the future, we will ex-
them to help them understand and mitigate the threat.
plore how to utilize existing exploitation stabilization techniques
to improve DirtyCred’s exploitation success rate.
TOCTOU. As discussed above, DirtyCred swaps credential objects 12 ACKNOWLEDGEMENT
in a critical time window. Intuition suggests that the existing TOC-
We thank the anonymous reviewers for their insightful feedback.
TOU defense mechanisms may hinder our proposed exploitation
This work was supported by ONR N00014-20-1-2008 and NSF 1954466.
method. According to a recent research article [44], TOCTOU de-
Any opinions, findings, conclusions or recommendations expressed
fense could be divided into source code detection, postmortem
in this material are those of the authors and do not necessarily
detection, system call interposition, intra/inter-process memory
reflect the views of the funding agency.

1975
CCS ’22, November 7–11, 2022, Los Angeles, CA, USA. Zhenpeng Lin, Yuhang Wu, and Xinyu Xing

REFERENCES [30] Max Kellermann. 2022. The Dirty Pipe Vulnerability. (2022). https://dirtypipe.
[1] 2022. DirtyCred: Escalating Privilege in Linux Kernel. (2022). https://zplin.me/ cm4all.com/
papers/DirtyCred.pdf [31] Vasileios P Kemerlis, Michalis Polychronakis, and Angelos D Keromytis. 2014.
[2] Kristen Carlson Accardi. 2020. Function Granular KASLR. (2020). https://lwn. ret2dir: Rethinking kernel isolation. In Proceedings of the 23rd USENIX Conference
net/Articles/824307/ on Security Symposium.
[3] Anonymous. 2022. DirtyCred Exploit. (2022). https://hackmd.io/ [32] Vasileios P Kemerlis, Georgios Portokalidis, and Angelos D Keromytis. 2012.
giRE2P2oQHektZzOG053IQ { kGuard } : Lightweight Kernel Protection against { Return-to-User } Attacks. In
[4] Alex Chapman. 2020. Privileged Container Escape Control Groups re- Proceedings of the 21st USENIX Conference on Security Symposium.
lease_agent. (2020). https://ajxchapman.github.io/containers/2020/11/19/ [33] Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss, Werner
privileged-container-escape.html Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, et al. 2019.
[5] Quan Chen, Ahmed M Azab, Guruprasad Ganesh, and Peng Ning. 2017. Spectre attacks: Exploiting speculative execution. In Proceedings of the 2019 IEEE
Privwatcher: Non-bypassable monitoring and protection of process credentials Symposium on Security and Privacy.
from memory corruption attacks. In Proceedings of the 2017 ACM on Asia Confer- [34] Zhenpeng Lin. 2021. How AUTOSLAB Changes the Memory Unsafety Game.
ence on Computer and Communications Security. (2021). https://grsecurity.net/how_autoslab_changes_the_memory_unsafety_
[6] Yueqi Chen, Zhenpeng Lin, and Xinyu Xing. 2020. A systematic study of elastic game/
objects in Kernel exploitation. In Proceedings of the 2020 ACM SIGSAC Conference [35] Zhenpeng Lin, Yueqi Chen, Yuhang Wu, Chensheng Yu, Dongliang Mu, Xinyu
on Computer and Communications Security. Xing, and Kang Li. 2022. GREBE: Unveiling Exploitation Potential for Linux
[7] Yueqi Chen and Xinyu Xing. 2019. Slake: Facilitating slab manipulation for Kernel Bugs. In Proceedings of the 2022 IEEE Symposium on Security and Privacy.
exploiting vulnerabilities in the linux kernel. In Proceedings of the 2019 ACM [36] Linux. 2022. FUSE’s introduction in the Linux kernel user’s and administrator’s
SIGSAC Conference on Computer and Communications Security. guide. (2022). https://www.kernel.org/doc/html/latest/filesystems/fuse.html
[8] Jonathan Corbet. 2012. Supervisor mode access prevention. (2012). https: [37] Linux. 2022. Userfaultfd’s introduction in the Linux kernel user’s and adminis-
//lwn.net/Articles/517475/ trator’s guide. (2022). https://www.kernel.org/doc/html/latest/admin-guide/mm/
[9] Jonathan Corbet. 2017. The current state of kernel page-table isolation. (2017). userfaultfd.html
https://lwn.net/Articles/741878/ [38] Moritz Lipp, Michael Schwarz, Daniel Gruss, Thomas Prescher, Werner Haas,
[10] The MITRE Corporation. 2021. CVE-2021-4154. (2021). https://cve.mitre.org/ Anders Fogh, Jann Horn, Stefan Mangard, Paul Kocher, Daniel Genkin, et al. 2018.
cgi-bin/cvename.cgi?name=CVE-2021-4154 Meltdown: Reading kernel memory from user space. In Proceedings of the 27th
[11] The MITRE Corporation. 2022. CVE-2022-0847. (2022). https://cve.mitre.org/ USENIX Conference on Security Symposium.
cgi-bin/cvename.cgi?name=CVE-2022-0847 [39] Derrick McKee, Yianni Giannaris, Carolina Ortega Perez, Howard Shrobe, Mathias
[12] John Criswell, Nathan Dautenhahn, and Vikram Adve. 2014. KCoFI: Complete Payer, Hamed Okhravi, and Nathan Burow. Preventing Kernel Hacks with HAKC.
control-flow integrity for commodity operating system kernels. In Proceedings of In Proceedings 2022 Network and Distributed System Security Symposium.
the 2014 IEEE Symposium on Security and Privacy. [40] Larry McVoy and Carl Staelin. 2022. LMbench - Tools for Performance Analysis.
[13] Datadog. 2022. Using the Dirty Pipe Vulnerability to Break Out (2022). http://lmbench.sourceforge.net/
from Containers. (2022). https://www.datadoghq.com/blog/engineering/ [41] Phoronix Media. 2022. Open-Source, Automated Benchmarking. (2022). https:
dirty-pipe-container-escape-poc/ //www.phoronix-test-suite.com/
[14] Lucas Davi, David Gens, Christopher Liebchen, and Ahmad-Reza Sadeghi. 2017. [42] Samsung Knox News. 2016. Real-time Kernel Protection (RKP). (2016). https:
PT-Rand: Practical Mitigation of Data-only Attacks against Page Tables.. In //www.samsungknox.com/en/blog/real-time-kernel-protection-rkp
Proceedings of the 2017 Network and Distributed Systems Security Symposium. [43] Sergej Proskurin, Marius Momeu, Seyedhamed Ghavamnia, Vasileios P Kemerlis,
[15] Jake Edge. 2013. Kernel address space layout randomization. (2013). https: and Michalis Polychronakis. 2020. xmp: Selective memory protection for kernel
//lwn.net/Articles/569635/ and user space. In Proceedings of the 2020 IEEE Symposium on Security and Privacy.
[16] Jake Edge. 2020. Control-flow integrity for the kernel. (2020). https://lwn.net/ [44] Razvan Raducu, Ricardo J. Rodríguez, and Pedro Álvarez. 2022. Defense and
Articles/569635/ Attack Techniques Against File-Based TOCTOU Vulnerabilities: A Systematic
[17] Dmitry Evtyushkin, Dmitry Ponomarev, and Nael Abu-Ghazaleh. 2016. Jump Review. IEEE Access 10 (2022), 21742–21758.
over ASLR: Attacking branch predictors to bypass ASLR. In 2016 49th Annual [45] Chengyu Song, Byoungyoung Lee, Kangjie Lu, William Harris, Taesoo Kim, and
IEEE/ACM International Symposium on Microarchitecture. Wenke Lee. 2016. Enforcing Kernel Security Invariants with Data Flow Integrity..
[18] Thomas Garnier. 2016. mm: SLAB freelist randomization. (2016). https://lwn. In Proceedings 2016 Network and Distributed System Security Symposium.
net/Articles/685047/ [46] Dan Williams. 2018. Randomize free memory. (2018). https://lwn.net/Articles/
[19] Xinyang Ge, Nirupama Talele, Mathias Payer, and Trent Jaeger. 2016. Fine- 767614/
grained control-flow integrity for kernel software. In Proceedings of the 2016 IEEE [47] Wei Wu, Yueqi Chen, Xinyu Xing, and Wei Zou. 2019. { KEPLER } : Facilitating
European Symposium on Security and Privacy. control-flow hijacking primitive evaluation for Linux kernel vulnerabilities. In
[20] google. 2022. Kernel Control Flow Integrity. (2022). https://source.android.com/ Proceedings of the 28th USENIX Conference on Security Symposium.
devices/tech/debug/kcfi [48] Wen Xu, Juanru Li, Junliang Shu, Wenbo Yang, Tianyi Xie, Yuanyuan Zhang,
[21] Google. 2022. Roses are red, Violets are blue, Giving leets more and Dawu Gu. 2015. From collision to exploitation: Unleashing use-after-free
sweets. All of 2022! (2022). https://security.googleblog.com/2022/02/ vulnerabilities in linux kernel. In Proceedings of the 22nd ACM SIGSAC Conference
roses-are-red-violets-are-blue-giving.html on Computer and Communications Security.
[22] Daniel Gruss, Moritz Lipp, Michael Schwarz, Richard Fellner, Clémentine Mau- [49] Sungbae Yoo, Jinbum Park, Seolheui Kim, Yeji Kim, and Taesoo Kim. 2021. In-
rice, and Stefan Mangard. 2017. Kaslr is dead: long live kaslr. In International Kernel Control-Flow Integrity on Commodity OSes using ARM Pointer Authen-
Symposium on Engineering Secure Software and Systems. 161–176. tication. arXiv preprint arXiv:2112.07213 (2021).
[23] Daniel Gruss, Clémentine Maurice, Anders Fogh, Moritz Lipp, and Stefan Man- [50] Kyle Zeng, Yueqi Chen, Haehyun Cho, Xinyu Xing, Adam Doupé, Yan Shoshi-
gard. 2016. Prefetch side-channel attacks: Bypassing SMAP and kernel ASLR. In taishvili, and Tiffany Bao. 2022. Playing for K(H)eaps: Understanding and Improv-
Proceedings of the 2016 ACM SIGSAC conference on computer and communications ing Linux Kernel Exploit Reliability. In Proceedings of the 31st USENIX Conference
security. on Security Symposium.
[24] HexRabbit. 2021. CVE-2021-34866 Writeup. (2021). https://github.com/
HexRabbit/CVE-writeup/tree/master/CVE-2021-34866
[25] Jann Horn. 2022. Linux: UAF via double-fdput. (2022). https://bugs.chromium.
org/p/project-zero/issues/detail?id=808
[26] David Howells. 2022. CREDENTIALS IN LINUX. (2022). https://www.kernel.
org/doc/Documentation/security/credentials.txt
[27] Kaiming Huang, Yongzhe Huang, Mathias Payer, Zhiyun Qian, Jack Sampson,
Gang Tan, and Trent Jaeger. 2022. The Taming of the Stack: Isolating Stack Data
from Memory Errors. In Proceedings of the 2022 Network and Distributed Systems
Security Symposium.
[28] Ralf Hund, Carsten Willems, and Thorsten Holz. 2013. Practical timing side chan-
nel attacks against kernel space ASLR. In Proceedings of the 2013 IEEE Symposium
on Security and Privacy.
[29] Mateusz Jurczyk. 2011. SMEP: What is it, and how to beat
it on Windows. (2011). https://j00ru.vexillium.org/2011/06/
smep-what-is-it-and-how-to-beat-it-on-windows/

1976