Defects-in-Depth: Analyzing the Integration

of Effective Defenses against One-Day

Exploits in Android Kernels
Lukas Maar, Graz University of Technology; Florian Draschbacher,
Graz University of Technology and A-SIT Austria, Graz; Lukas Lamster
and Stefan Mangard, Graz University of Technology
https://www.usenix.org/conference/usenixsecurity24/presentation/maar-defects

This paper is included in the Proceedings of the

33rd USENIX Security Symposium.
August 14–16, 2024 • Philadelphia, PA, USA
978-1-939133-44-1

Open access to the Proceedings of the

33rd USENIX Security Symposium
is sponsored by USENIX.
Defects-in-Depth: Analyzing the Integration of Effective Defenses against One-Day
Exploits in Android Kernels

Lukas Maar Florian Draschbacher

Graz University of Technology Graz University of Technology and A-SIT Austria
Lukas Lamster Stefan Mangard
Graz University of Technology Graz University of Technology

Abstract EF:
ET1 ET2 ET2
With the mobile phone market exceeding one billion units CVE root privileges
sold in 2023, ensuring the security of these devices is critical.
However, recent research has revealed worrying delays in Figure 1: The exploitation flow EF is a vulnerability-agnostic
the deployment of security-critical kernel patches, leaving chain of exploitation techniques ET, with one ET elevating a
devices vulnerable to publicly known one-day exploits. While primitive to a more powerful form [8]. EF leverages the capa-
the mainline Android kernel has seen an increase in defense bilities of a vulnerability to gain root privileges ultimately.
mechanisms, their integration and effectiveness in vendor-
supplied kernels are unknown at a large scale.
In this paper, we systematically analyze publicly available Despite the importance of mobile security, recent stud-
one-day exploits targeting the Android kernel over the past ies [13, 27, 43, 61, 67] have revealed that Android’s security-
three years. We identify multiple exploitation flows repre- critical kernel patches often lag significantly behind the main-
senting vulnerability-agnostic strategies to gain high privi- stream Linux kernel. In over 20 % of cases, delays exceed-
leges. We then demonstrate that integrating defense-in-depth ing one year occur [61], mainly due to the downstream ap-
mechanisms from the mainline Android kernel could mitigate proach of most Android vendors. This delayed deployment of
84.6 % of these exploitation flows. In a subsequent analysis of security-critical patches creates opportunities for malicious
994 devices, we reveal a widespread absence of effective de- actors to attack the Android Linux kernel. While these attacks
fenses across vendors. Depending on the vendor, only 28.8 % would be classified as one-day exploits due to the known na-
to 54.6 % of exploitation flows are mitigated, indicating a ture of their vulnerabilities, they effectively function as zero-
4.62 to 2.951 times worse scenario than the mainline kernel. day exploits during the extensive unpatched period. The sever-
Further delving into defense mechanisms, we reveal weak- ity of this situation is underscored by findings from Google
nesses in vendor-specific defenses and advanced exploitation Project Zero [9, 49] and Threat Analysis Group [50], which
techniques bypassing defense implementations. As these de- highlight a prevalence of exploits in the wild targeting these
velopments pose additional threats, we discuss potential solu- unpatched vulnerabilities in the Android kernel.
tions. Lastly, we discuss factors contributing to the absence On the defensive side, the mainline Android kernel has
of effective defenses and offer improvement recommenda- seen an increase in vulnerability-agnostic defenses preventing
tions. We envision that our findings will guide the inclusion one-day exploits. While these defense-in-depth mechanisms
of effective defenses, ultimately enhancing Android security. may be readily available, their integration and effectiveness
in vendor-supplied kernels are unknown. Consider, for exam-
ple, the case of the Pegasus spyware. Using BadBinder, an
1 Introduction exploit [46] known since 2019, malicious actors can infect
target devices with their payload. While an effective defense
Over the past decade, the mobile phone market has reached
has been available for over 10 years [47], its rollout status
an all-time high, with more than one billion units sold in 2023.
in vendor-provided kernels is entirely opaque. The question-
Given our daily reliance on mobile phones for communication,
able deployment or absence of such defenses leaves devices
financial transactions, and personal data storage, this surge
vulnerable to one-day exploitation flows (see Figure 1), thus
in device adoption underscores the critical need for robust
creating a significant security gap in the Android ecosystem.
security measures protecting these devices.
Malicious actors can exploit this and mount attacks against
1 Factors 1−0.288 1−0.546
of 1−0.846 and 1−0.846 , respectively. insufficiently protected devices based on public exploits.

USENIX Association 33rd USENIX Security Symposium 4517

 In this paper, we address the inadequate protection of An- relation. We present factors such as a lack of importance
droid devices against one-day exploitation flows through com- of security features and vulnerable configurations, as well
prehensive analysis. We systematically analyze all publicly as performance costs (confirmed by Google, Samsung, and
available one-day exploits targeting memory safety vulnera- Huawei), which are particularly relevant for low-end devices.
bilities in the Android Linux kernel over the past three years, We also make recommendations to Google and downstream
comprising 26 exploits. In doing so, we unveil the diversity vendors to improve Android security.
of these one-day exploits and classify 10 distinct exploitation We open source2 our tools that detect the widespread lack
techniques. In a subsequent analysis, we examine 8 defense- of included and effective defenses.
in-depth mechanisms present in the mainline Android kernel Contributions. The main contributions of our work are
and find that they effectively prevent 84.6 % of the previously (1) One-Day Exploitation Insights: We analyze 26 one-day
identified one-day exploitation flows. This percentage serves exploits and classify 10 different exploitation techniques.
as the ground truth for how secure mobile devices could be if (2) Defense Insights: Based on these insights, we demon-
their kernels were up to date with the defenses enabled. Given strate defenses for the identified techniques.
the maximum achievable security, we can quantify the level (3) Defense Inclusion and Effectiveness Analysis: We un-
of security that is actually reached in Android devices. veil a significant gap between the maximum available
For this, we conduct the first large-scale analysis on kernel- security and that reached by vendor-supplied kernels.
level defense-in-depth mechanisms for Android devices via (4) Novel Findings: We present in-depth insights into the
a mostly automated approach. We demonstrate a widespread absence of effective defenses in vendor-supplied ker-
absence across vendors and uncover flaws in vendor-specific nels, exploitation advancements, weaknesses, and factors
defenses. In our analysis, we cover Android devices from all likely contributing to the absence of defense.
top 7 vendors (e.g., Samsung, Xiaomi, and Huawei), along Disclosure. We disclosed our findings to all 10 vendors.
with three recognized vendors (i.e., Google, OnePlus, and While some did not respond (e.g., Oppo and Xiaomi), others
Fairphone), covering more than 84 % of the global Android (i.e., Google, Fairphone, Motorola, Huawei, and Samsung)
device share [6]. We analyze devices from 2018 to 2023 using acknowledged our findings (fully or partially), and some of
Android versions 9 to 14 and kernels ranging from v3.10 to these patched unsecured phones to enhance Android security.
v6.1. In total, we analyze 994 device firmwares and 1533 Outline. Section 2 provides background. Section 3 shows
Android kernel source codes. Our results suggest that the the high-level workflow. Section 4 presents the one-day anal-
level of security that is actually reached is severely lacking ysis and defense identification. Section 5 presents the large-
compared to the mainline Android kernel. scale defense analysis. Sections 6 and 7 discuss potential
Our work presents four novel findings. First, we provide solutions and related work. Section 8 concludes our work.
in-depth insights into the absence of effective defenses in
vendor-provided kernels. On average, only 41.5 % of our ana-
lyzed one-day exploitation flows can be mitigated. This varies 2 Background
across vendors, from 28.8 % for the least (i.e., Fairphone) to
54.6 % for the most secure (i.e., Google) vendor, indicating a 2.1 Android Ecosystem and Android Kernels
4.62 to 2.95 times worse scenario than the ground truth.
Android is primarily designed for mobile devices and under-
Second, we unveil advancements in two exploitation tech-
goes active development led by Google. The Android kernel
niques, enabling malicious actors to bypass the defense in-
is based on the Linux kernel. For major platform releases,
tended against the base technique. These advancements are
Google specifies compatible launch kernels for new devices
applicable in all one-day exploitation flows that use the base
and upgrades kernels for existing device updates.
technique. While these advancements pose additional threats
Historically, vendors maintained separate Linux kernel
to Android devices, we discuss potential mitigations.
trees for each product model, hindering upstream bug fixes
Third, we uncover 4 and 2 distinct weaknesses in Sam- due to vendor-specific code and hardware drivers. Despite the
sung’s and Huawei’s vendor-specific defenses, respectively. introduction of monthly Android Security Bulletins in 2015,
These issues impact Samsung devices ranging from Galaxy prior research [24, 67] indicates continued delay in patch inte-
A04/A14 to Galaxy S23 5G/Ultra, and, thus, the entire range gration. In response, Google introduced the Generic Kernel
of low-end to high-end devices, as well as the entire range Image (GKI) project in Android 11 on kernel versions above
of Huawei devices. We demonstrate that these defenses do or equal to v5.4, aiming to overcome slow patch adoption.
not fully prevent the targeted exploitation technique, or we This initiative separates the Android kernel into a hardware-
demonstrate modified exploits that bypass the defense. agnostic core maintained by Google and vendor-specific mod-
Fourth, we discuss factors that may contribute to the lack ules loaded dynamically. Moreover, it restricts the Android
of effective defenses. While we observe a correlation between kernel to some constraints, such as ABI compatibility.
older kernel versions and higher one-day susceptibility, we
reveal that susceptibility extends beyond mere version cor- 2 https://github.com/IAIK/DefectsInDepth.

4518 33rd USENIX Security Symposium USENIX Association

2.2 Kernel Exploitation in-cache reuse, the adversary reuses the freed memory slot
for another object that lives in the same slab cache. This only
Fundamental Kernel Defenses. The Linux kernel employs works in caches that contain the vulnerable and reallocated
defense-in-depth mechanisms to make vulnerability exploita- objects, e.g., kmalloc-* caches. Hence, the adversary is lim-
tion more difficult. These are included via the configuration ited to objects that have the same (or similar) size and the
file .config. One fundamental defense is the WˆX policy, same allocation properties as the vulnerable object.
which dictates that sections may never be writeable and ex- The other way is to use a cross-cache reuse [33, 38, 60] at-
ecutable. Consequently, an attacker cannot simply inject in- tack. Here, the adversary frees all slots of a slab page, prompt-
structions for privilege escalation. Kernel Address Space ing the slab allocator to return the slab page that contains the
Layout Randomization (KASLR) randomizes the location vulnerable object to the page allocator. The page is then allo-
of binary sections at boot time. Thus, an exploit typically cated either as a different type of page or to another slab cache.
breaks KASLR through a read primitive or a side channel [21]. This allows them to reuse a memory slot between slab caches
Lastly, Privilege Access Never (PAN) prevents access to of different types, allocation sizes, and allocation properties.
user-accessible memory while in kernel space, mitigating Out-Of-Bounds. Exploiting an OOB vulnerability [12,65]
the control-flow redirection to userspace. with write capabilities follows a similar process. An adversary
Kernel Exploitation on Android. The exploitation flow triggers the OOB write, often in the form of a linear over-
(see Figure 1) of most Android kernel exploits consists of flow, to manipulate sensitive data in an adjacent memory slot
three stages: First, an adversary breaks KASLR to identify the (i.e., victim object). This sensitive data typically references
locations of critical structures. Second, the adversary obtains a vulnerable object, e.g., through a reference counter or data
an arbitrary read-and-write primitive that allows them to pointer [38,42]. The adversary then forces the memory slot of
perform the third step, which is gaining full root privileges. the vulnerable object into a state where it is referenced twice.
To break KASLR, an adversary typically triggers a memory This upgrades the OOB write to be exploited analogously to
safety vulnerability, e.g., Use-After-Free (UAF) or Out-Of- the UAF three-stage exploitation flow typically.
Bounds (OOB) access, to leak a kernel address. By knowing
the Android kernel binary under attack, the adversary then
computes the kernel base address. Depending on how power-
3 High-Level Workflow
ful the underlying vulnerability is, the adversary either contin- This section presents the high-level workflow of our study,
ues or re-triggers this (or another) vulnerability to obtain an depicted in Figure 2. It consists of three main components:
arbitrary read-and-write primitive. They then typically ma- the One-Day Exploitation Analysis and Defense Inclusion and
nipulate credentials to elevate their privileges. Furthermore, Effectiveness Analysis, both of which yield Novel Findings.
they tamper with kernel memory to disable SELinux’s Manda- In the One-Day Exploitation Analysis (see Section 4), we
tory Access Control (MAC), obtaining full root privileges. manually analyze all publicly available one-day exploits tar-
Kernel Heap Attacks. Since most memory-safety vulner- geting memory safety vulnerabilities in the Android Linux
abilities concern heap-allocated memory [65], dynamically kernel from the last three years. Our goal is to identify the ex-
allocated during runtime, it is a popular attack target. ploitation flows employed in these exploits. In this context, we
Use-After-Free. UAF vulnerabilities occur when a re- refer to an exploitation flow (see Figure 1) as a vulnerability-
source that is still referenced is freed. A typical UAF exploit agnostic chain of exploitation techniques that exploit a vulner-
works as follows: First, an adversary causes the memory slot ability to gain full root privileges. An exploitation technique
of a vulnerable object that is still in use to be freed. Freeing is a reusable and reasonably generic strategy for transforming
the memory slot causes the allocator to reuse the slot for future an exploit primitive into a more powerful one [8]. In our study,
allocations. Second, they allocate a reallocated object such we analyze 26 one-day exploits and uncover a diverse range
that the vulnerable and reallocated objects simultaneously use of exploitation flows, with 10 used exploitation techniques. In
the previously freed slot. Third, they use either the vulnerable a subsequent analysis, we identify 8 defense-in-depth mecha-
or the reallocated object to obtain a read or write primitive for nisms present in the mainline Android kernel v6.1, mitigating
the slot. Exploiting a Double-Free (DF) or Invalid-Free (IF) most exploitation techniques and, hence, 84.6 % of exploita-
vulnerability (which are special cases of a UAF, where the tion flows. This percentage serves as the ground truth for the
slot is either freed twice or with an offset) works similarly. maximum achievable security of mobile devices.
In practice, several challenges render such attacks more In the Defense Inclusion and Effectiveness Analysis (see
difficult to execute. Most vulnerabilities grant only weak write Section 5), we collect Android kernels released by all top
capabilities, such as zeroing out memory at a particular offset. mobile phone vendors (i.e., Samsung, Xiaomi, Oppo, Vivo,
Additionally, to successfully exploit a UAF, the adversary Realme, Huawei, Motorola, Google, OnePlus, and Fairphone)
requires knowledge of how the kernel’s allocator (i.e., slab between 2018 and 2023. Our goal is to determine the inclusion
allocator) reuses memory slots. and effectiveness of defense mechanisms in protecting these
There are generally two ways to exploit this reuse: With mobile devices. For this, we collect 994 device firmwares and

USENIX Association 33rd USENIX Security Symposium 4519

 One-Day Exploitation Analysis (see 4)
Widespread absence of
included and effective
defenses (see 5.3.1).

Search for Identify Techniques Identify defenses preventing Availability for Advancement in two
Exploit collector exploitation techniques
one-day exploits exploit flow classification kernel versions
exploitation techniques
One-Day Exploit Collection Exploit Analysis Defense Identification (see 5.2.3 and 5.2.4).

Weaknesses in
custom defenses
(see 5.2.5 and 5.2.6).
Kernel source
code

Metadata
Factors potentially
Identified Inclusion and
Web crawler Kernel collector storage contributing to this
Firmware image devices effectiveness
Android Kernel Collection Metadata Extraction Defense Analysis situation (see 6).

Defense Inclusion and Effectiveness Analysis (see 5) Novel Findings

Figure 2: The high-level workflow of our study where indicates fully automated and indicates mostly automated.

1533 kernel source codes. Our analysis reveals that a signifi- lection consists of one-days exploiting memory safety vul-
cant portion of the analyzed device firmwares lacks multiple nerabilities, as the Android kernel has established defenses
defenses, and some of the defenses are flawed, leaving de- to prevent their exploitation. By including other vulnerabili-
vices vulnerable to multiple of the one-day exploitation flows ties, such as logical (e.g., CVE-2022-22706) and GPU (e.g.,
analyzed in our one-day exploitation analysis. CVE-2023-33107) flaws, we expect that the susceptibility
Our analysis reveals four Novel Findings. First, we reveal to one-day exploits increases as the mainline Android ker-
the widespread absence (see Section 5.3.1) of included and nel does not yet effectively mitigate them. Our study spans
effective defenses against one-day exploitation flows across the last 3 years, from 2020 to November 2023. This aligns
vendors. Second, we demonstrate advancements in two ex- with Google Project Zero’s efforts to track zero-day exploits
ploitation techniques (see Sections 5.2.3 and 5.2.4). While targeting Android devices. Earlier public exploits are less
these advancements enable bypassing the defense intended documented, so we focus on this more recent timeframe [48].
against the base techniques, we discuss potential solutions.
Third, we uncover 4 and 2 weaknesses (see Sections 5.2.5
and 5.2.6) in Samsung’s and Huawei’s custom defense, respec- 4.1 Identified Exploitation Techniques
tively. Lastly, we discuss (see Section 6) factors potentially We observe that most one-day exploits have distinct exploita-
contributing to the absence of effective defenses and offer tion flows to convert one or more memory safety vulnerabili-
improvement recommendations. ties into either an arbitrary read-and-write primitive or code
modification (see Table 1). By examining these exploitation
4 One-Day Exploitation Analysis flows, we identify 10 exploitation techniques.
We refer to an exploitation technique as a strategy for turn-
In this section, we elaborate on our systematic analysis of all ing one exploitation primitive into a more powerful one, with
publicly available one-day exploits targeting memory safety examples of primitives being n-byte OOB write, UAF write,
vulnerabilities in the Android Linux kernel over the past three program counter control, or arbitrary read and write. We clas-
years. We identify and examine 26 exploits, demonstrating sify exploitation techniques based on strategies that recur over
that their exploitation flow uses one or more of the 10 exploita- multiple one-days and are reasonably generic [8]. An example
tion techniques outlined in Section 4.1. These techniques fol- of a technique is control-flow hijacking, which turns program
low a generic strategy for transforming an exploit primitive counter control into code execution and is used by multiple
into a more powerful one. In Section 4.2, we demonstrate that one-days. Another example is the unlink operation, which
defense-in-depth mechanisms present in the Android kernel may turn an OOB or UAF write of a double-linked list into a
v6.1 can mitigate 22 (i.e., 84.6 %) one-day exploitation flows. once-triggerable write or read primitive.
Lastly, Section 4.3 demonstrates that the remaining 4 one-day ET1: Unlink Operation. By exploiting a vulnerability,
exploits either exploit substantially powerful vulnerabilities or an adversary ensures that a victim object resides in the same
can be mitigated by a defense currently in development [44]. memory slot as a double-linked list, i.e., list_head with
One-Day Exploits. We obtained 26 one-day exploits (see next and prev (see Listing 1). The adversary then initiates
Table 1) from public sources, e.g., Google Project Zero [49], the unlinking via list_del, resulting in a write to the victim
Blackhat [35], Github [41], or other websites [58]. Our se- object. The one-days CVE-2019-2215, CVE-2019-2025, and

4520 33rd USENIX Security Symposium USENIX Association

Table 1: Exploitation flow used by publicly available one-day exploits, where defense-in-depth mechanisms present in the
Android Linux kernel v6.1 can ✓ or cannot ✗ prevent the exploitation flow. The exploitation flow is preventable depending on ✶
Samsung’s RKP [15] variant. Two one-day exploits ✩ exploit the same CVE with different exploitation flows.
CVE Vulnerabilities Exploitation flow Goal Primitive Preventable
CVE-2019-2215 UAF in-cache reuse → unlink operation → KASLR leak, in-cache reuse → unlink operation → addr_limit overwrite arbitrary r/w ✓
CVE-2019-2025 ✩ UAF in-cache reuse → unlink operation → KASLR leak, in-cache reuse → unlink operation → file overwrite arbitrary r/w ✓
CVE-2020-0030 UAF in-cache reuse → unlink operation → KASLR leak, in-cache reuse → unlink operation → addr_limit overwrite arbitrary r/w ✓
CVE-2021-1968,-1969,-1940 UAF leak attacker-controlled data location, KASLR leak, in-cache reuse → CFH → ret2bpf arbitrary r/w ✓
CVE-2021-0920 UAF in-cache reuse → unlink operation → KASLR leak → pipe_buffer overwrite arbitrary r/w ✓
CVE-2021-1905 UAF cross-cache reuse → tamper allocator meta-data → KASLR leak → CFH → ret2bpf arbitrary r/w ✓
CVE-2022-22265 DF in-cache reuse → KASLR leak, cross-cache reuse → pipe_buffer overwrite arbitrary r/w ✓
CVE-2021-25369,-25370 Leak, UAF KASLR leak, in-cache reuse → file overwrite → CFH → addr_limit overwrite arbitrary r/w ✓
CVE-2016-3809,-2021-0399 Leak, UAF KASLR leak, in-cache reuse → seq_file overwrite → CFH → ret2bpf arbitrary r/w ✓
CVE-2022-20409 UAF in-cache reuse → KASLR leak → pipe_buffer overwrite arbitrary r/w ✓
CVE-2023-21400 DF cross-cache reuse → Dirty PageTable arbitrary r/w ✓
CVE-2022-28350 UAF cross-cache reuse → Dirty PageTable arbitrary r/w ✗/✶
CVE-2020-29661 UAF cross-cache reuse → Dirty PageTable arbitrary r/w ✗/✶
CVE-2021-22600 DF in-cache reuse → KASLR leak → pipe_buffer overwrite arbitrary r/w ✓
CVE-2020-0423 UAF in-cache reuse → KASLR leak → unlink operation → KSMA code modification ✓
CVE-2022-22057 UAF in-cache reuse → KASLR leak → slab freelist corruption → KSMA code modification ✓
CVE-2023-26083,-0266 Leak, UAF KASLR leak, in-cache reuse → ctl_file overwrite → CFH arbitrary r/w ✗
CVE-2020-0041 UAF in-cache reuse → KASLR leak, in-cache reuse → unlink operation → tamper sysctl arbitrary r/w ✓
CVE-2019-2205 UAF in-cache reuse → KASLR leak, in-cache reuse → unlink operation → tamper binder_proc arbitrary r/w ✓
CVE-2019-2025 ✩ UAF in-cache reuse → KASLR leak, in-cache reuse → unlink operation → KSMA code modification ✓
CVE-2020-3680 UAF in-cache reuse → KASLR leak → unlink operation → KSMA code modification ✓
CVE-2022-20421 UAF cross-cache overflow → KASLR leak → pipe_buffer overwrite arbitrary r/w ✓
CVE-2022-0847 Uninit Variable uninitialized pipe → DirtyPipe → overwrite the cached file page arbitrary r/w ✓
CVE-2021-4154 UAF in-cache reuse → DirtyCred → overwrite shared library arbitrary r/w ✗
CVE-2021-38001 OOB R/W OOB write → stack manipulation → KASLR leak → OOB write → stack manipulation → CFH → ret2bpf arbitrary r/w ✓
NO_NUMBER (∼2021) OOB W OOB write → slab freelist corruption → pipe_buffer DF → KASLR leak → pipe_buffer overwrite arbitrary r/w ✓
22/26

1 struct list_head { 1 struct binder_thread { 1 u64 access_ok(const void __user *addr, u64 size) {
2 struct list_head *next; 2 struct list_head wait; 2 return (u64)((u65)addr + (u65)size <= (u65)current->
3 struct list_head *prev; 3 struct task_struct *task; addr_limit + 1);
4 }; 4 }; 3 }
5 /* Unlinks element e */ 5 void remove_wait_queue( 4 u64 copy_from_user(void *to, const void __user *from, u64 n) {
6 void list_del(list_head *e) { binder_thread *bt) { 5 u64 res = n;
7 e->next->prev = e->prev; 6 /* Trigger unlinking */ 6 if (access_ok(from, n))
8 e->prev->next = e->next; 7 list_del(&bt->wait); 7 res = raw_copy_from_user(to, from, n);
9 } 8 } 8 return res;
9 }
Listing 1: Unlinking operation. Listing 2: Trigger unlinking.
Listing 3: Userspace data copy function validates with
access_ok whether addr refers to userspace memory.
iovec array
binder_thread_1 binder_thread_2 ① binder_thread_1 binder_thread_2 ②
wait: wait: wait: wait:
next next next next iov_len
prev prev prev prev iov_base

er/size, commonly used for file reading or writing. Executing

next: bt2.wait next: bt3.wait next: bt2.wait iov_len: 0x1000
prev: bt0.wait prev: bt1.wait prev: bt0.wait iov_base: 0x800000 remove_wait_queue on the first wait entry (bt1.wait)
iovec array
binder_thread_2 ③ ssize_t readv(...) { ④ overwrites the iov_base of the second wait entry with
wait: copy_to_user(iovec->iov_base,f->pdata); bt1.wait->prev ③ (at Line 7 of list_del). Consequently,
next iov_len }
prev iov_base
ssize_t writev(...) { the buffer iovec now points to binder_thread_0.wait
copy_from_user(f->pdata,iovec->iov_base);
iov_len: 0x1000 } (short bt0.wait). These exploits then use the iovec read-
iov_base: bt0.wait
/write functionality ④ (e.g., readv or writev) to write to
Figure 3: Exploitation example of the unlink operation. or read from the iovec->iov_base and, hence, bt0.wait.
This approach is used to leak binder_thread->task and
overwrite task->addr_limit. While this example shows
CVE-2020-0030, for example, leverage this unlink operation the usage of iovec (which has been fixed for v4.13 [2]),
to first leak binder_thread->task, whose layout is shown other security-critical objects can also be misused, e.g.,
in Listing 2, and then overwrite task->addr_limit (ET2). msg_msg [42] or pipe_buffer in CVE-2021-0920.
Figure 3 illustrates an exploitation example [46], where ini- ET2: addr_limit Overwrite. This technique turns a
tially, an adversary prepares a double-linked list ①. They then task->addr_limit overwrite into an arbitrary read and
exploit a vulnerability to ensure that the second wait entry write. AArch64 kernels below v5.11 include addr_limit in
(binder_thread_2.wait or short bt2.wait) resides in the task, which holds the highest address accessible within user-
same memory slot ② as an iovec object. This iovec stores a data copy functions, e.g., copy_*_user. These functions call
user buffer, with iov_base/len being the user buffer’s point- access_ok to validate that the user address is lower than

USENIX Association 33rd USENIX Security Symposium 4521

 ① ② 4 kiB Page
pipe_buffer pipe_buffer eventfd_ctx
Level 2
page page count
offset offset kernel pgd Level 1
len len D_Page
D_Table_1
Level 0 1 GiB Page
D_Table_0
writable kernel code
③ ssize_t pipe_read(...) ④ D_Block_M user/kernel accessible
ssize_t eventfd_signal_mask
{ copy_to_user(pipe_buffer->page,uaddr); }
(eventfd_ctx *ctx, u64 n)
ssize_t pipe_write(...)
{ ctx->count += n; }
{ copy_from_user(uaddr,pipe_buffer->page); }
Figure 5: KSMA: Due to a write capability to page table level
0, an adversary maliciously overwrites the D_Block_M entry
Figure 4: Exploiting pipe_buffer to obtain an arbitrary r/w.
to refer to kernel code as writable and user accessible.

addr_limit (see Line 6 of Listing 3), aiming to ensure user

address access. However, by overwriting addr_limit with argument register, and a controllable data region. In ret2bpf,
KERNEL_DS (i.e., -1), an adversary can deceive the kernel into a data region is crafted to contain valid eBPF [7] instructions,
legally accessing kernel memory within these copy functions. performing, for instance, an arbitrary read and write. With
Hence, syscalls (e.g., read and write) using these copy func- the CFH primitive and the crafted eBPF instructions, ret2bpf
tions can be misused as an arbitrary read-and-write primitive. performs a CFH attack to execute ___bpf_prog_run(regs,
inst). This function interprets the crafted eBPF instructions
ET3: pipe_buffer Overwrite. Overwriting the
as if the eBPF verifier had validated them. Here, inst is the
pipe_buffer yields an arbitrary read and write as follows.
data region holding the crafted eBPF instructions, and regs
Initially, an adversary requires an arbitrarily triggerable
represents a writable section used for registers.
overwrite capability for a pipe_buffer object that is still in
use. One approach is to exploit a UAF vulnerability so that ET6: Slab Freelist Corruption. This exploitation tech-
a pipe_buffer and a specific object (e.g., eventfd_ctx nique turns a once-only OOB or UAF write into a memory
or signalfd_ctx) reside in the same memory slot. Since slot overwrite capability. It requires a memory slot that is
this specific object is writable from userspace, it enables currently in the freed state. By exploiting a write capabil-
manipulating pipe_buffer (e.g., eventfd_ctx for CVE- ity on this free slot (e.g., zeroing memory due to a UAF
2021-22600). Another approach enforces the coexistence or OOB write), an adversary manipulates a freelist pointer
of a pipe_buffer and the backed physical page of another stored within the free slot. Then, by allocating an object, the
pipe_buffer in the same slot (cf. CVE-2022-22265). adversary illegally reclaims the memory slot referenced by
Figure 4 illustrates the exploitation of CVE-2021-22600. the corrupted freelist pointer. This allocated object typically
In ①, the memory layout of a pipe_buffer is shown with grants overwrite capabilities for the reclaimed memory slot.
its members page, offset, and len. Step ② exploits the vul- ET7: KSMA. Yong et al. [63] introduced the Kernel-
nerability where afterward pipe_buffer and eventfd_ctx Space Mirroring Attack (KSMA), which transforms a once-
reside in the same memory slot, and page and count coex- triggerable write primitive into a kernel code manipulation
ist on the same address. Calling eventfd_signal_mask ③ capability. This transformation is done by manipulating a
allows to change count and, hence, pipe_buffer->page. page table level 0, called Page Global Directory (PGD) (e.g.,
Consequently, pipe_read/write ④ read from or write to swapper_pg_dir), representing the kernel address space.
this controlled address, granting an arbitrary read and write. Specifically, KSMA forges an entry within the kernel’s
ET4: Control-Flow Hijacking. Various one-day exploits page table level 0, designating its address range as accessible
perform a Control-Flow Hijacking (CFH) attack, leveraging from user and kernel space. This forged entry is marked as
an overwrite capability of either a function pointer or a pointer a 1 GB huge page and references kernel code. Consequently,
to a function pointer. Compared to x86_64 exploitation, they the entire kernel code (including kernel data) is readable and
do not resort to Return-Oriented Programming (ROP) [10]. writable from userspace. The page-table layout after perform-
Instead, they identify an execution path resulting in an arbi- ing KSMA is shown in Figure 5 with a 3-level page-table
trary read-and-write primitive. For instance, CVE-2023-0266 translation (i.e., 39 bit Virtual Address Size (VA_SIZE) and
overwrites the f_ops pointer (referencing a table of function 4 kiB page size, but it works similarly for other configura-
pointers for file interactions) of ctl_file. As a result, the tions). This kernel code modification is then utilized to disable
syscalls read and write confuse the void *pdata mem- SELinux and manipulate a syscall to elevate the privileges.
ber of ctl_file, leading to a misuse of copy_*_user and ET8: Dirty PageTable. Dirty PageTable [58] shows how
yielding an arbitrary read-and-write primitive. page-table tampering results in an arbitrary read and write on
ET5: Ret2bpf. Ret2bpf serves as an alternative to ROP, Android (where Maar et al. [38] show generic page-table ma-
offering a similarly potent capability [7, 28]. Its prerequi- nipulation). It exploits a UAF (cf. CVE-2022-28350 and CVE-
sites [28] involve hijacking the control flow (ET4), partial 2020-29661) or DF (cf. CVE-2023-21400) for a cross-cache
control of the first argument register, control over the second attack [60]. This causes an object with arbitrary overwrite

4522 33rd USENIX Security Symposium USENIX Association

 4 kiB Page Table 2: Mitigation of one-day exploits, using ✓ to indicate de-
Level 2 fenses that prevent used exploitation techniques. Conversely,
user pgd Level 1 D_Page ✗ indicates ineffective defenses (see Sections 5.2.3, 5.2.4
Level 0
D_Table_1 D_Page_M
4 kiB Page and 5.2.6). Samsungs’s defenses ✗/✶ are either ineffective or
D_Table_0
writable arbitrary only effective in certain variants (see Section 5.2.5).
user accessible physical page

CVE ²  ⋔ / ® Ó 
CVE-2019-2215 ✓ ✗ ✓ ✓
Figure 6: Dirty PageTable: With an arbitrary page table level CVE-2019-2025 ✓ ✓
2 write capability, an attacker tampers the D_Page_M entry to CVE-2020-0030 ✓ ✗ ✓ ✓
refer to an arbitrary page as writable and user accessible. CVE-2021-1968,-1969,-1940 ✓ ✓ ✗
CVE-2021-0920 ✓ ✓
CVE-2021-1905 ✓ ✓ ✗
CVE-2022-22265 ✓
capabilities (e.g., signalfd_ctx for CVE-2023-21400) to CVE-2021-25369,-25370 ✗ ✓ ✗ ✗ ✓
CVE-2016-3809,-2021-0399 ✓ ✓ ✓ ✗
reside in the same memory slot as a page table used for user CVE-2022-20409 ✓
address translation. Figure 6 shows this, where an adversary CVE-2023-21400 ✓ ✶ ✗
CVE-2022-28350 ✶ ✗
has an arbitrary overwrite to the page-table entry D_Page_M CVE-2020-29661 ✶ ✗
due to the cross-cache attack. By triggering the overwrite, CVE-2021-22600 ✓
CVE-2020-0423 ✓ ✗ ✓ ✓
they gain control over the page frame number of this entry. CVE-2022-22057 ✓ ✗ ✓ ✓
Reading or writing to the user address using this page-table CVE-2023-26083,-0266 ✗ ✗
CVE-2020-0041 ✓ ✓
entry gives them arbitrary physical memory access. CVE-2019-2205 ✓ ✓
ET9: DirtyPipe. The DirtyPipe attack [30] exploits an CVE-2019-2025 ✓ ✓ ✗ ✓ ✓
uninitialized variable to escalate privileges. The CVE-2022- CVE-2020-3680 ✓ ✓ ✗ ✓ ✓
CVE-2022-20421 ✓
0847 vulnerability allows to use the pipe_buffer.flags CVE-2022-0847 ✓
variable uninitialized. Consequently, this vulnerability allows CVE-2021-4154
CVE-2021-38001 ✓ ✓ ✗
overwriting of any file contents in the page cache, also in the NO_NUMBER (∼2021) ✓ ✓
case of read-only files, which results in privilege escalation. ² DM1: CONFIG_DEBUG_LIST  DM2: CONFIG_ARM64_UAO DM3: kmalloc-cg-*
⋔ DM4: CONFIG_CFI_CLANG / DM5: CONFIG_BPF_JIT_ALWAYS_ON
ET10: DirtyCred. The DirtyCred exploit [34] allows an ® DM6: CONFIG_SLAB_FREELIST_HARDENED DM7: CONFIG_INIT_ON_ALLOC_DEFAULT_ON
DM8: KSMA protection Ó DM9: Samsung RKP  DM10: Huawei HKIP
attacker to escalate privileges. It exploits a file UAF to free
a writable file currently in use. Prior to this invalid free, it
performs a write operation to the file and stalls this write DM3: kmalloc-cg-*. Linux kernels above v5.13 sup-
operation. After the free, it reclaims the file object for a read- port heap segregation at the allocator cache level. It separates
only high-privilege file. Continuing the stalled write operation caches to provide a designated cache for security-critical data
now writes to the read-only high-privilege file. With this file marked as accounted, such as for msg_msg, pipe_buffer,
manipulation, DirtyCred can, e.g., overwrite a kernel module file, and task_struct. For generic caches, a cache for
with malicious code to construct an arbitrary read and write. non-security-critical data (i.e., kmalloc-*) and a cache for
security-critical data (i.e., kmalloc-cg-*) are created. Free
and available cached objects will never share the same mem-
4.2 Defenses to Prevent Exploitation Flows
ory slots within these caches. Hence, this mitigates the
We identify 10 defense-in-depth mechanisms present in the pipe_buffer overwrite (ET3) and unlink operation (ET1
Android kernel v6.1 or provided by vendors. They prevent with security-critical objects), as these techniques rely on
exploitation techniques and, hence, exploitation flows, with security-critical and non-security-critical data sharing the
the findings shown in Table 1 and detailed in Table 2. same memory slot. While adversaries might consider cross-
DM1: CONFIG_DEBUG_LIST. This defense includes cache attacks, three challenges arise with this approach, mak-
checks in del_list whether e->next->prev == e and ing the transition infeasible. First, for generic caches, the
e->prev->next == e. If these checks fail, the entry will success rate significantly decreases to 40 % [60], with failure
not be unlinked. Thus, it mitigates the unlink operation (ET1). scenarios potentially resulting in a crash. The small success
In Figure 3, for instance, overwriting from step ② to ③ is rate makes this approach impractical since the cross-cache
prevented as iovec->iov_base is not equal to bt1.wait. reuse only pertains to a small part of the exploit and may need
DM2: CONFIG_ARM64_UAO. User-Access Over- multiple repetitions. Second, exploits that engage in cross-
ride (UAO) [9] is a hardware-enforced defense that aims cache attacks typically rely on prior in-cache reuse attacks
to mitigate addr_limit overwrite (ET2). It introduces to stabilize the exploit. For instance, CVE-2022-22265 sta-
new unprivileged load and store instructions that behave bilizes by in-cache reallocating the double-freed slot of the
like privileged ones when the UAO bit is set. This restricts pipe_buffer as an iovec multiple times. Separating the
user-data copy functions, e.g., copy_*_user, from being pipe_buffer from objects intended for stabilizing, such as
misused to read from or write to kernel addresses directly. iovec, makes the exploit unstable, mostly resulting in a crash,

USENIX Association 33rd USENIX Security Symposium 4523

successfully preventing exploitation. A similar applies to hypervisor. Hypervisor calls or exceptions to the hypervisor
CVE-2023-21400, where seq_operations (accounted) are permit legitimate writes to these protected pages. Protecting
prevented from being in-cache reallocated as signalfd_ctx CFI metadata only provides additional protection for modules
(not accounted). Third, various UAF exploits (e.g., CVE-2021- and not against the CFH technique. Similarly, protecting the
0399) offer a tight time window in which an in-cache attack is eBPF-interpreted code does not prevent against ret2bpf, as it
exploitable. In contrast, cross-cache attacks require more time only safeguards the already interpreted instructions.
due to the recycling/reclaiming of the slab page to/from the Further defenses. The ongoing research in improv-
page allocator [60], making small windows not exploitable. ing kernel security yielded results with various kernel de-
DM4: CONFIG_CFI_CLANG. Control-Flow In- fenses. For instance, CONFIG_HARDENED_USERCOPY restricts
tegrity (CFI) [1,3] restricts the control flow to an approximate copy_*_user from reading and writing out of bounds [59].
Control-Flow Graph (CFG), limiting the targets for CFH Other examples include CONFIG_INIT_STACK_ALL_ZERO
attacks (ET4). The Android kernel uses Clang’s implementa- mitigating uninitialized stack variable exploitation [37] and
tion [3], providing function-signature-grained CFI. It prevents CONFIG_STACKPROTECTOR_STRONG providing stack protec-
CFH attacks that overwrite function pointers with arbitrary tion [45]. While these defenses cover a broad range of vulner-
functions, e.g., CVE-2021-1905 and CVE-2021-0399. ability mitigation, our focus is specifically on defenses against
DM5: CONFIG_BPF_JIT_ALWAYS_ON. To mitigate one-day exploitation flows on the Android kernel (DM1-10).
ret2bpf (ET5), this defense mechanism forces BPF to always
use the JIT engine instead of the interpreter. Consequently, the 4.3 Unpreventable Exploitation Flows
___bpf_prog_run function used by ret2bpf is not compiled
and, therefore, cannot be called, preventing ret2bpf. We identify 4 one-day exploitation flows targeting the An-
DM6: CONFIG_SLAB_FREELIST_HARDENED. To droid kernel that remains unpreventable by mainline defenses.
mitigate the manipulation of slab allocator metadata, this de- Among these, DirtyCred (cf. CVE-2021-4154) presents a pow-
fense hardens the slab allocator by adding sanity checks. This erful technique that falls beyond the defense prevention scope.
includes XORing the freelist pointer with a pseudo-random A similar applies to the CFH one-day (cf. CVE-2023-26083,-
number, preventing slab freelist corruption (ET6). 0266), redirecting the control flow to perform an arbitrary
DM7: CONFIG_INIT_ON_ALLOC_DEFAULT_ON. It read and write without violating signature-based CFI.
zeroes out the memory slot for both allocations by the page While our identified defenses do not effectively prevent two
and slab allocator. Consequently, it greatly minimizes the ex- other one-days (Dirty PageTable, cf. CVE-2022-28350 and
ploitability of uninitialized values. It prevents the exploitation CVE-2020-29661), researchers are actively developing a new
of DirtyPipe (ET7) as the uninitialized pipe_buffer.flags defense mechanism specifically designed to counter cross-
cannot be misused to overwrite file content in the page cache. cache reuse attacks [44]. This mitigation strategy involves
DM8: KSMA Protection. In response to KSMA (ET8), switching the allocation of memory slots cached by the slab
researchers proposed to move all kernel level 0 global page allocator from physical to virtual pages, thereby preventing
tables (e.g., swapper_pg_dir and tramp_pg_dir) to a read- the reuse of slab pages returned by the page allocator.
only section [62]. As a result, these page tables cannot be
manipulated for a huge kernel memory mapping (e.g., 1 GiB) 5 Defense Inclusion & Effectiveness Analysis
that is writable from userspace, thus preventing KSMA.
DM9: Samsung RKP. Samsung’s Real-time Kernel Pro- In this section, we outline our systematic analysis demonstrat-
tection (RKP) [15] employs hypervisor-based protection de- ing a widespread deficiency of included defense mechanisms
signed to mitigate code modification, data modification, and across vendors as well as shortcomings of certain defenses.
control-flow hijacking in the kernel. To address kernel code Our approach (see Figure 2) consists of three mostly auto-
modification, RKP ensures the integrity of page tables (ET8 mated stages: Initially, we collect kernel source codes and
and ET9) and code by mapping them as read-only, protected firmwares (see Section 5.1) for Android devices from 10 ven-
by the hypervisor. Hypervisor calls permit legitimate writes to dors. We then analyze kernel codes (see Section 5.2) to assess
these protected pages. RKP also limits CFH attacks (ET4) by the effectiveness of defenses provided by the mainline kernel
including checks before indirect branches that restrict control- or vendors. Lastly, we analyze firmwares (see Section 5.3) to
flow transfers to a function-grained CFG. detect included effective defenses in devices.
DM10: Huawei HKIP. Huawei Kernel Integrity Protec- Android Devices. For our analysis (done in November
tion (HKIP) [25] employs hypervisor-based protection that 2023), we cover Android devices from vendors that constitute
protects kernel code and critical kernel data. It also limits priv- more than 84 % [6] of the global market. These include the
ilege escalation and protects additional control-flow-related top 7 vendors [6], i.e., Samsung, Xiaomi, Oppo, Vivo, Huawei,
data. To achieve this, HKIP ensures the integrity of certain Realme, and Motorola, along with Google, OnePlus, and Fair-
page tables (ET8 and ET9), addr_limit (ET2), CFI meta- phone. We assess devices released between 2018 and 2023,
data, and eBPF interpreted code by protecting them via the utilizing Android versions 9 through 14 and kernels ranging

4524 33rd USENIX Security Symposium USENIX Association

 ① Level 3
from v3.10 to v6.1. These Android versions account for a Level 2 4 kiB Page
kernel pgd
share of more than 86 % [5], with specific percentages for Level 1
D_Table_2
D_Page

Level 0
Android 13, 12, 11, 10 and 9, being 25.7 %, 21.3 %, 17.3 %, D_Table_1

13.9 %, and 8.7 %, respectively. Android 14, while at a negli- D_Table_0

read-only
gible market share at the moment, is also considered.
② 4 kiB Page
We decided to start with phones released in November Level 3
Level 2
2018 (5 years from the start of this work), as the lifespan of kernel pgd
Level 1 D_Page

Android phones is 4-6 years (4y for Huawei, 5y for Google, Level 0
D_Table_1
D_Table_2
1 GiB Page

and 6y for Samsung) [17, 54]. Hence, our selection ensures a D_Table_M ❷
D_Block_M
writable kernel code
❸ user/kernel accessible
comprehensive overview of the current device landscape. ❶ writable

Figure 7: Advanced KSMA: ① Initial 4-level page table

5.1 Collection of Firmwares and Kernel Codes translation with the level 0 table mapped as read-only. ② Mod-
ifies the level 0 mapping to mark it as writable ❶, overwrites
This step automatically collects firmwares (not protected by
D_Table_M ❷, and appends D_Block_M ❸, to have a 1 GiB
captchas) and kernel code. To achieve this, we implement a
mapping accessible from userspace.
Python script using Selenium that crawls web pages to collect
firmwares and kernel source code from our 10 vendors. We
manually collected firmware protected by captchas or other CONFIG_ARM64_UAO (DM2), which is hardware-dependent.
automation detections (i.e., ≈ 45.3 %). Although our analysis might identify this defense as present,
Firmwares. Our 10 vendors produced 1698 devices be- this defense can be bypassed, as we demonstrate in Sec-
tween November 2018 and November 2023 (see Table 4). For tion 5.2.4. Hence, regardless of whether it is enabled, it does
1109 of them, firmwares were provided, where we only con- not protect addr_limit overwrite (ET2).
sidered the most recent release either officially (e.g., Google)
or via an intermediate supplier (e.g., Oppo).
Kernel Codes. We collected 1533 kernel codes (see Ta- 5.2.2 Identified Downstream Defenses
ble 4) with different releases for the same device (e.g., Sam- Some vendors provide custom defenses to improve kernel
sung and Huawei) where available. Other vendors (e.g., security. We semi-automatically analyze the 1533 collected
Google and Vivo) use the same kernel code for multiple de- kernels and provide evidence of 3 vendor-specific downstream
vices, resulting in less collected code than firmwares. defenses against the identified exploitation techniques. The
analysis works as follows: First, we automatically collect the
5.2 Analysis of Kernel Source Codes configuration flags in the ./security subdirectory and in the
files that require changes to mitigate exploitation techniques,
We examine kernel source codes for efficacy against exploita- e.g., vmlinux.ld.S and mmu.c to prevent KSMA (ET8).
tion techniques. Initially, we provide evidence that our iden- Second, we manually analyze those flags collected from down-
tified defenses (see Sections 5.2.1 and 5.2.2) reflect the real stream kernels that are not present in the mainline kernel
world of mitigating exploitation techniques. However, we (i.e., Google). Our analysis results in Samsung RKP (DM9),
also identify shortcomings in these defenses. We show that Huawei HKIP (DM10), and CONFIG_PG_DIR_RO from Vivo
they can be bypassed, indicating that their efficacy is less (which we consider in the firmware analysis as DM8). We
than intended due to advanced techniques (see Sections 5.2.3 also received confirmation from Fairphone and Motorola that
and 5.2.4) or weaknesses (see Sections 5.2.5 and 5.2.6). they do not include vendor-specific defenses.

5.2.1 Mainline Defenses in Downstreamed Kernels 5.2.3 Advanced Kernel-Space Mirroring Attack
7 of the 8 mainline defense mechanisms are intrinsically tied Despite the KSMA mitigation patch, we present an advance-
to the core functionality of the Android kernel: ment in reenabling KSMA. Its prerequisite is the same con-
• Associating specific defenses with versions (i.e., DM3). straint write capability as the base KSMA (ET8), but it uses
• Not compiling dangerous functions (i.e., DM5). it twice: First, it changes the mapping of the level 0 PGD
• Replacing non-hardened with hardened functions (i.e., to writable, and second, it maliciously inserts the page-table
DM1/4/6/7/8). entry into the PGD. For a 48 bit VA_SIZE system with 4-level
For example, CONFIG_DEBUG_LIST (DM1) uses the hard- translation, our technique triggers the write three times, as
ened function __list_add_valid to validate metadata depicted before ① and after ② the attack in Figure 7. The
in double-linked lists. Another example is kmalloc-cg-* first write changes the PGD mapping to writable ❶, while the
(DM3), which utilizes a segregated set of allocator caches second changes the PGD entry to user accessible ❷. The third
for kernel versions 5.13 and above. The exception is write inserts then the entry ❸ in the page-table level 1.

USENIX Association 33rd USENIX Security Symposium 4525

 For this technique, the locations of three page-table write operation. Moreover, setting addr_limit to USER_DS
pages (level 0, level 1, and level 3’ corresponding to prevents the second write to kernel memory.
the mapping level 0 as read-only) are crucial. Depend- However, since addr_limit operates at thread granularity,
ing on whether CONFIG_UNMAP_KERNEL_AT_EL0 is active, we spawn two threads, T1 and T2, where we only illegally
swapper_pg_dir or tramp_pg_dir is used as a level 0 page. overwrite the addr_limit of T2 with KERNEL_DS. We lever-
A KASLR code leak, combined with knowledge of the ker- age T1 to perform the first write and T2 for the second write.
nel binary under attack, is sufficient to obtain these locations As a result, we can bypass UAO without further restrictions.
since both locations are mapped to a fixed offset to the kernel Prior work [9] has presented similar bypasses.
base address. This step is also needed for the base KSMA. Mitigation. A mitigation would be to remove the
Both level 1 and level 3’ are allocated via the page allo- addr_limit functionality or use kernels above v5.11, which
cator during the early initialization stages and accessed via do not support addr_limit anymore.
the Direct-Physical Mapping (DPM) [39], which is a virtual
memory mapping to the entire physical memory. Since the
5.2.5 Samsung RKP Weaknesses
page allocator returns the same physical page during differ-
ent boots, their locations can be determined. The DPM may We inspect Samsung RKP [15], designed to prevent page-table
be randomized on newer Android kernels (e.g., v6.1). To manipulation and limit CFH attacks. However, we demon-
overcome randomization, a heap address leak is typically suf- strate that various RKP variants only protect certain page ta-
ficient to derandomize the DPM, as the kernel heap uses the bles and, thus, do not mitigate page-table manipulation. They
DPM directly. Typically, leaking a heap address requires no also provide less CFH protection than the mainline defense.
additional effort beyond leaking the kernel base address. Analysis. For each of these findings, we provide statistical
Armed with the three page-table locations, our advanced data on their occurrence, collected using the following ap-
KSMA uses the write capability three times to obtain kernel proach. We first perform automated source code analysis, fol-
code modification, which no mainline defense can prevent. lowed by manual verification. We then conduct experiments
The level of difficulty of our advancement is similar to the to demonstrate the severity of these identified problems.
base KSMA, but the write capability is triggered three times, Findings. First, some kernels have RKP disabled and
and for recent Android versions, a heap leak is required. do not map tramp/swapper_pg_dir or tramp_pg_dir as
Experiments. Our setup involves a buildroot filesystem read-only. Compared to the mainline defense, this results in
with an Android kernel (aarch64 with a 48 bit VA_SIZE), less security as an adversary can directly perform KSMA. We
specifically v5.15 and v6.1. We run it inside a virtual machine found this weakness mostly in low-end devices such as Galaxy
with 4 cores and 4 GB RAM via QEMU 6.2.0. We introduce A04/A14 (i.e., released 2022/2023), missing both pages and
a write primitive and run our exploits as an unprivileged user, Galaxy M10 (i.e., released 2019), missing tramp_pg_dir,
giving them the same capabilities as the base KSMA version. representing 25.4 % and 1.7 % of kernels, respectively.
As a result, we successfully execute our advanced KSMA and Second, while some variants protect page tables used for
obtained an arbitrary code modification primitive. userspace address translation, we observe a strong tendency
Mitigation. Our advanced KSMA requires the locations to exclude this protection towards new high-end devices such
of all mapping page tables that are not randomized during the as Galaxy S23 5G. Specifically, we observe that less than
early initialization process. Hence, an adversary can still de- 53 % of devices include this protection, indicating that more
duce their location by knowing the kernel binary under attack than 47 % are vulnerable to Dirty PageTable [58].
(and a heap leak for v6.1). To counteract the advanced KSMA, Third, CONFIG_FASTUH_RKP is a performance-optimized
we propose randomizing the locations of the page tables dur- RKP variant included in over 60 % of all v5.4 kernels, pro-
ing this early initialization stage, ensuring that adversaries viding a maximum number of read-only pages protected by
cannot obtain information about the page’s location. the hypervisor. If the system demands more, RKP resorts to
allocating unprotected pages. An adversary can exhaust these
5.2.4 Shortcoming of User Access Override read-only protected pages and, subsequently, perform Dirty
PageTable. This performance-optimized RKP variant is avail-
The UAO feature is believed to prevent the addr_limit able for lower-end devices, e.g., Samsung Galaxy J6, and for
overwrite (ET2) [36] effectively. This technique manipu- high-end devices, e.g., Samsung Galaxy S20 FE and S21+ 5G.
lates addr_limit with KERNEL_DS to facilitate, for example, Similarly, CONFIG_TIMA_RKP provides similar weak protec-
pipes for arbitrary kernel reads and writes. Specifically, it tion for page tables, mainly used by older devices.
first writes the pointer to a userspace buffer to one pipe end. Fourth, CONFIG_RKP_CFP_JOPP/_ROPP aim to mitigate
It then performs a read syscall with a kernel address as an CFH attacks [15] by providing function-granular CFI (JOPP)
argument, prompting the userspace copy function to write the and return address protection (ROPP). However, our analysis
userspace buffer’s content to this kernel address. With UAO of exploitation flows reveals that all 6 CFH attacks redirect
enabled, setting addr_limit to KERNEL_DS prevents the first the control flow with at least function granularity. Hence, both

4526 33rd USENIX Security Symposium USENIX Association

defenses are ineffective in mitigating any of the CFH attacks.

lsy f
n
g
e

kal el.el
.bi
m
① ② ③

war

ms
t.i
Experiments. For the first weakness, we use the same

nel
Kernel ELF &

Firm

n
boo

ker
ker
setup as for our advanced KSMA technique and overwrite Boot Image Kernel Binary Symbols
Extraction Extraction Conversion
unprotected page-table pages to perform KSMA. We then
implement POCs for the other weaknesses on a Samsung
Galaxy S20 FE, where we modify the kernel code to obtain Figure 8: Workflow of extracting kernel.elf and kallsyms
the corresponding primitive. For the second weakness, we from the firmware, required for the defense detection.
use the introduced write primitive for a page table used for a
userspace address translation to successfully perform Dirty
PageTable. For the third weakness, we demonstrate that we detection. It first extracts the boot image ① using open-source
can drain the protected pages with memory exhaustion. We tools, which requires different tools [22, 31, 32, 51, 55] as ven-
then prompt the kernel to allocate a page that should be pro- dors encode the boot image differently. It then extracts the
tected, but this is not due to memory exhaustion. For the fourth kernel binary ② using unpack_bootimg [35]. Lastly, it uses
weakness, we demonstrate that RKP does not mitigate control- kallsyms_finder and vmlinux_to_elf to reconstruct the
flow hijacking to arbitrary functions. As a result, control-flow symbols (i.e., kallsyms) and convert the kernel binary to an
protection does not prevent the 6 CFH attacks we analyzed. analyzable ELF (i.e., kernel.elf) ③ [40].
The kallsyms and kernel.elf components form the ba-
sis of defense detection. Our Python script uses kallsyms to
5.2.6 Huawei HKIP Weaknesses
identify global functions within the kernel binary, allowing
We examine Huawei’s HKIP [25], particularly regarding the us to deduce the active defense mechanisms. The presence of
protection against KSMA and Dirty PageTable. __list_add_valid in kallsyms, for instance, indicates the
Analysis. We observe that HKIP is only included in cer- status of CONFIG_DEBUG_LIST (DM1). Our script does simi-
tain devices and enabled in about 62 %. In the following, we lar assessments for other defenses (see Table 3). It uses the
analyze HKIP and experimentally demonstrate the absence kernel.elf to determine the status of KSMA protection
of protection for crucial page-table pages. (DM8) and CONFIG_SLAB_FREELIST_HARDENED (DM6).
Findings. First, HKIP protects page-table pages that For KSMA protection, all PGDs (e.g., swapper_pg_dir)
are allocated for kernel address translations (e.g., via must be mapped in a read-only section. The presence of
pte_alloc_one) in a specific virtual address range. As a re- calling get_random_long within __kmem_cache_create
sult, HKIP does not protect page tables for userspace address indicates the status of CONFIG_SLAB_FREELIST_HARDENED.
translations, leaving devices vulnerable to Dirty PageTable. Our evaluation also includes five features for system
Second, while HKIP protects the ttbr (hardware register security; KASLR (CONFIG_RANDOMIZE_BASE), code write
that stores the current PGD for address translation) switch, protection (CONFIG_STRICT_KERNEL_RWX), freelist random-
it may not be compatible with frequent ttbr switching de- ization (CONFIG_SLAB_FREELIST_RANDOM), restricting user
fenses, i.e., software PAN (CONFIG_ARM64_SW_TTBR0_PAN) access in kernel (CONFIG_ARM64_(SW_TTBR0_)PAN), and
switches the ttbr for each copy_*_user and Meltdown pro- Meltdown protection (CONFIG_UNMAP_KERNEL_AT_EL0).
tection (CONFIG_UNMAP_KERNEL_AT_EL0) for each user ker- Evaluated Firmwares. Out of the 1698 released and 1109
nel switch. No device has HKIP with either one of these two collected devices, our analysis extracted 994 firmwares, re-
enabled, leaving these devices vulnerable to KSMA. sulting in a collection rate of 58.5 %, which aligns with prior
Experiments. We could not run experiments with the work on reverse engineering firmwares [11, 14, 64].
Huawei kernel source codes as they either had compilation Due to the unavailability of certain firmwares, our analysis
errors, no defconfig (e.g., ranchu64) viable for virtual en- could not cover all released devices. However, we observed
vironments or failed to boot in QEMU. Therefore, we adapted that the missing firmwares are distributed either normally
a Google kernel v4.14 to tag pages that HKIP would have regarding device age, such as those from Huawei and Vivo,
protected. For our page-table manipulation attacks, we ex- or tailored to older devices, as seen with Xiaomi and Realme.
perimentally observed that HKIP does not protect page-table Given our finding that older devices tend to include fewer
pages that KSMA and Dirty PageTable manipulate. defenses, our analysis provides conservative results. Thus, we
anticipate the real-world scenario to be even more concerning.
5.3 Analysis of Firmwares
5.3.1 Analysis Results
This work refers to the firmware as the stock ROM, the origi-
nal software loaded onto the device by the vendor. It consists We fully automate the detection of included defenses. Table 5
of multiple images [4], such as the system and boot image. presents the defenses included for each vendor’s firmwares.
Figure 8 shows the automated workflow of our implemented Our results indicate a lack of basic defenses (e.g., PAN and
Python script, extracting the necessary metadata for defense KASLR) and a significant lack of defenses against one-day ex-

USENIX Association 33rd USENIX Security Symposium 4527

 # Vendor # Vendor

① 1 Google 6 Samsung
2 Realme 7 Motorola
3 OnePlus 8 Huawei
❶ 4 Xiaomi 9 Oppo
5 Vivo 10 Fairphone

②
(a) Ground truth (b) Ranking

Figure 9: Susceptible one-day exploitation flows of all device

images. While ① indicates that 281 images are susceptible
to 21 or more one-day exploitation flows and ② indicates (c) Samsung (d) Xiaomi
913 images to 10 or more, the ❶ line represents the average
susceptibility of 15.2 exploitation flows of all 994 images.

ploit flows. In particular, significant portions of the firmwares

do not include defenses such as CONFIG_DEBUG_LIST, which
is critical to mitigate BadBinder [46].
Susceptibility. Using data from Section 5.2 and Table 2, (e) Oppo (f) Vivo
we evaluate the effectiveness and assess the susceptibility
of firmwares to one-day exploitation flows. We consider a
firmware to be susceptible to a one-day exploitation flow if it
does not include a defense that can prevent the vulnerability-
agnostic exploitation flow. Figure 9 illustrates the overall
susceptible one-day exploitation flows per firmware with two
curves. The dashed line depicts the impact of the widespread (g) Realme (h) Huawei
defense lack, while the outer line incorporates both the lack
and efficacy shortcomings (see Section 5.2), providing a more
comprehensive view. Without these shortcomings, on aver-
age, nearly two one-day exploitation flows could have been
prevented. Both findings highlight the worrying situation and
lack of effective defenses to prevent exploitation flows.
Takeaway 1
(i) Motorola (j) Google
Even though effective defenses (see Table 2) for a large
share of the one-day exploitation flows are available, they
are rarely activated in vendor-provided kernels.

Susceptibility per Vendor. We further organize the re-

sults by vendor, presenting each in Figure 10. Figure 10a de-
picts the ground truth, showcasing the maximum achievable
security with all available mainline defenses. Figure 10c-10l (k) OnePlus (l) Fairphone
show each vendor’s susceptible one-day exploitation flows,
including the lack of defenses and efficacy shortcomings. We Figure 10: Analysis results per devices for each vendors.
specifically highlight Google, Fairphone, and Samsung, repre-
senting the most and least secure, and with the highest market
share. Their susceptibility is 11.8, 18.5, and 16.1, respectively, Takeaway 2
while the ground truth has 4. We compute the factor by which Protection against one-day exploitation flows is highly
they are worse than the ground truth, resulting in 2.95 (≊ 11.8
4 ), vendor dependent, varying between a 4.62 to 2.95 worse
4.62, and 4. Figure 10b presents the ranking of vendors ac- scenario than applying all available mainline defenses.
cording to this deterioration factor.

4528 33rd USENIX Security Symposium USENIX Association

 100%
Samsung nan% 3.7% 8.5% 6.7% 28.7% 26.8% 9.1% 8.5% 7.9% nan% Ground truth 13.0 12.0 12.0 12.0 9.0 9.0 9.0 9.0 4.0 4.0 25

Xiaomi nan% nan% 0.7% 4.9% 88.1% 5.6% 0.7% nan% nan% nan% Samsung nan 26.0 25.5 23.3 19.8 15.2 7.9 7.2 2.3 nan
80%
Oppo nan% 5.3% 6.1% 21.1% 25.4% 28.9% 10.5% 2.6% nan% nan% Xiaomi nan nan 26.0 26.0 12.1 16.1 12.0 nan nan nan 20

Vivo 3.5% 1.4% 3.5% 14.6% 29.9% 26.4% 7.6% 8.3% 2.1% 2.8% Oppo nan 26.0 26.0 26.0 18.2 13.0 12.0 10.0 nan nan
60% Vivo 22.0 26.0 26.0 25.1 15.2 12.8 12.0 10.0 4.0 4.0 15
Realme nan% nan% nan% 5.9% 44.4% 27.4% 14.1% 5.9% 2.2% nan%
Realme nan nan nan 26.0 12.6 11.2 10.9 10.0 4.0 nan
Huawei 1.7% 1.7% 7.6% 13.4% 55.5% 5.9% 8.4% 5.9% nan% nan%
40% Huawei 22.0 26.0 24.4 21.1 15.7 12.0 21.0 10.0 nan nan
10
Motorola nan% 2.9% 9.6% 10.6% 21.2% 26.9% 14.4% 13.5% 1.0% nan%
Motorola nan 26.0 26.0 26.0 18.2 13.1 11.9 10.0 4.0 nan
Google nan% nan% nan% 11.5% 11.5% 11.5% nan% 57.7% 7.7% nan%
Google nan nan nan 22.0 12.0 12.0 nan 10.0 4.0 nan
20% 5
Oneplus nan% nan% nan% 4.8% 16.7% 23.8% 21.4% 23.8% 7.1% 2.4%
Oneplus nan nan nan 26.0 14.3 14.4 12.0 10.0 4.0 4.0

Fairphone nan% nan% nan% 33.3% nan% 33.3% 33.3% nan% nan% nan% Fairphone nan nan nan 26.0 nan 10.0 12.0 nan nan nan
0% 0

.10
.18

.4
.9
.14
.19

.4
.10
.15

.1
.10
.18

.4
.9
.14
.19

.4
.10
.15

.1

v4
v4

v5

v6
v4
v4

v5

v6

v3
v3

v4
v4

v5
v5
v3
v3

v4
v4

v5
v5

Figure 11: Applied Android kernel versions for each vendor. Figure 12: Susceptible exploitation flows per version/vendor.

Susceptibility per Kernel Version. To illustrate a version Takeaway 4

dependency, we initially obtain the used kernel versions. Fig- There is a significant gap of 23.8 % between the one-day
ure 11 shows the results covering v3.10 to v6.1. For context, susceptibility of high-end and low-end devices.
v4.19 was released in 2018, while v3.10 was released in 2014.
We then analyze the susceptibility to one-day exploitation
flows, organized by kernel version and vendor (see Figure 12).
The figure includes a ground truth, representing how many ex- 6 Discussion
ploitation flows remain susceptible for a given kernel version
Factors Potentially Contributing to the Absence of Ef-
with all available defenses integrated (see Table 6).
fective Defenses. Our analysis, highlighted in Takeaway 1,
Three findings emerge from this analysis: First, almost
reveals a concerning reality: vendors lack the inclusion and
no device kernel prior to v4.14 includes any defenses. Since
effectiveness of defenses against one-day exploitation flows.
ret2bpf (ET5) is not exploitable on v3.10, it may be less
Here we discuss potential factors contributing to this situation.
susceptible than v3.18. Second, newer kernels tend to have
First, as indicated by Takeaway 2, there is variability in
more active protection against exploitation flows, observed
susceptibility to one-day exploitation flows across vendors.
across almost all vendors. This is particularly true for those
While Google and OnePlus demonstrate lower susceptibility,
obeying the GKI constraints (≥v5.4 for GKI-1.0 or ≥v5.10
others like Huawei show higher ones. As these vendors utilize
for GKI-2.0). Third, although newer kernels provide more
different kernel versions, we observe a correlation between
defenses, a v3.10 kernel with all available defenses enabled
higher susceptibility and the use of older versions. Hence, a
would protect more flows than 38.1 % of our analyzed kernels.
potential contributing factor is the use of older kernel versions.
Takeaway 3 Second, as emphasized in Takeaway 3, susceptibility ex-
While newer kernels provide more defenses, a v3.10 kernel tends beyond mere kernel version correlation. Even the dep-
with all available defenses enabled would mitigate more recated kernel v3.10 (released about ten years ago) would
exploitation flows than 38.1 % of vendor-supplied kernels. mitigate more one-day exploitation flows, if properly config-
ured, than 38.1 % of vendor firmwares. Huawei underscores
Susceptibility per Low/High-End Device. We differen- this statement with their v5.4.86 kernels, nearly twice as bad
tiate the susceptibility according to whether it is a low-end as the properly configured v3.10. This lack of proper configu-
or a high-end device: We initially compute the average one- ration appears prevalent across multiple vendors. Hence, the
day susceptibility of the latest low-end and high-end devices second potential contributor is a lack of importance regarding
from vendors offering both classes, i.e., all except Google and security-relevant features for the Android kernel.
Fairphone (see Table 7). We then compute the susceptibil- Third, as shown in Takeaway 4, we observe that low-end are
ity reduction of high-end compared to low-end devices. For more susceptible to one-day exploitation flows than high-end
instance, with a susceptibility score of 4.5 and 5.5 for high- devices, as observed by most vendors. On the one hand, low-
end and low-end Samsung devices, respectively, the reduction end devices tend to be less powerful than high-end devices,
is 18.2 %. Overall, the reduction is between 0 % to 63.6 %, and on the other hand, enabling defenses increases the perfor-
with an average value of 23.8 %, which indicates a significant mance overhead. To compensate for this performance cost,
reduction of high-end to low-end devices. vendors may deliberately not enable defenses for performance

USENIX Association 33rd USENIX Security Symposium 4529

gains. Therefore, the third potential factor is performance cost, 7 Related Work
especially for less powerful low-end devices.
Recommendation to Improve Android Security. With Large-scale Firmware Analysis. Possemato et al. [43] in-
these insights, we propose that Google updates the Android vestigated compliance with Android’s compatibility guide-
Compatibility Definition Document (CDD), which outlines lines and found customizations as security drawbacks. Sub-
the requirements for devices to be compatible with An- sequent work [24] has highlighted delays in adopting critical
droid. While for Android 14 some fundamental defenses are patches. Other studies scanned ROMs for insecure access
recommended (e.g., CONFIG_CFI_CLANG) or required (e.g., policies [16, 23] or privacy-intruding apps [20, 24, 52]. For
CONFIG_STRICT_KERNEL_RWX), other critical ones are ab- embedded systems, researchers have uncovered vulnerabil-
sent (e.g., CONFIG_DEBUG_LIST). By including our findings, ities at a large scale [14, 19] and revealed a reluctance to
we anticipate a substantial improvement in Android security. activate attack mitigations in Linux-based IoT devices [64].
Responses. Google responded that they are aware of this Android Security Patch Ecosystem. Prior works stud-
problem and are gradually enforcing kernel defenses that ied the deployment of security updates to Android sys-
will be integrated. However, as defenses can come at a per- tems. Wu et al. [57] noted that most Android Security Bul-
formance cost, enforcing them across all vendors is diffi- letin (ASB) issues stem from native code. Farhang et al. [18]
cult, especially for low-end devices. They pointed out that found that CVEs in the kernel took the longest to propagate to
CONFIG_DEBUG_LIST has been enforced in the past, but ven- vendor ASBs, while other researchers [29, 67] reported weeks
dors complained about the performance hit. This resulted in to months of delay in deploying Android security updates.
critical defenses not being integrated. Samsung and Huawei Patch Detection. Researchers proposed strategies to de-
responded similarly, as integration comes at a performance tect patches in kernel binaries. Zhang et al. [66] presented
cost, i.e., Samsung for not activating RKP on all (especially a detection approach by deriving a signature from the main-
low-end) devices and Huawei for not protecting all page tables. stream version, which is then compared with target kernels.
These responses highlight our third potential contribution fac- PDiff [27] statically extracts the semantics of source-level
tor. Fairphone and Motorola acknowledged our findings and patches and uses a similarity-based measure to detect patches
integrated defenses, while the others did not respond. in compiled kernels. Dynamic approaches [26, 68] automati-
cally adapt existing PoC exploits to different kernel variants.
Automation and Standardization. Fully automating the
Vulnerability Patching. Researchers have proposed solu-
analysis process would enhance the demonstration of the ef-
tions to address the long delays in kernel patch deployment.
fectiveness of defenses. We have already automated several
Wang et al. [56] prevented bugs discovered by a sanitizer from
steps, such as parts of the firmware and kernel code acquisi-
being triggered and, hence, exploited till a patch is available.
tion, metadata extraction, and defense analysis, all of which
Talebi et al. [53] instrumented vulnerable syscall implementa-
are scalable. Challenges remain in the acquisition and anal-
tions to undo harmful side-effects. Other researchers focused
ysis of zero-days and the acquisition of all firmware. Our
on downstream Android kernels. Chen et al. [13] proposed
work addresses these challenges manually and encourages
hot-patching with Lua code to filter vulnerable function argu-
standardization, drastically reducing manual effort. Therefore,
ments. Xu et al. [61] extended this by suggesting automated
our work addresses current technical challenges and encour-
binary hot patches from source-level upstream fixes.
ages progress for future identification of effectively integrated
Zero-Day Analysis. Google Project Zero [9, 45, 49] and
defenses, ultimately improving Android security.
Threat Analysis Group [50] hunt for zero-days in the wild.
False Negatives/Positives. A false negative occurs when
They release public findings covering various entities, e.g.,
we interpret a device as being susceptible to an exploitation
Android phones, significantly enhancing system security.
flow when it is not. This could have happened if we have over-
looked defenses. To ensure we identified all mainline defenses,
we executed each exploitation technique (ET1-10) with se- 8 Conclusion
curity measures enabled, resulting in the defenses (DM1-8)
preventing these exploits. To ensure that we have identified This work conducted a one-day analysis of Android devices,
all downstream defenses, we performed a semi-automated combined with an analysis of defense inclusion and effec-
analysis of the 1533 downstream kernels in Section 5.2.2, tiveness. Our findings unveiled a significant gap between the
which yielded 3 vendor-specific defenses. While misinter- current state of Android security and its maximum potential.
preted firmware analysis could also lead to false negatives, We discussed potential contributing factors and offered rec-
most defenses are intrinsically tied to the kernel’s core func- ommendations for improvement, enhancing Android security.
tionalities. As described in Section 5.2.1, those defenses that
are not intrinsically tied can only lead to false positives, i.e., Acknowledgements
we interpret a device as mitigating an exploitation flow when
it does not. This means our results can be interpreted as con- We thank Mathias Oberhuber, Andreas Kogler, the anony-
servative, and the real world may be even more worrying. mous reviewers, and our shepherd for their valuable feedback.

4530 33rd USENIX Security Symposium USENIX Association

This project has received funding from the Austrian Research [12] Weiteng Chen, Xiaochen Zou, Guoren Li, and Zhiyun
Promotion Agency (FFG) via the SEIZE project (FFG grant Qian. KOOBE: Towards Facilitating Exploit Genera-
number 888087). Any opinions, findings, conclusions, or rec- tion of Kernel Out-Of-Bounds Write Vulnerabilities. In
ommendations expressed in this paper are those of the authors USENIX Security, 2020.
and do not necessarily reflect the views of the funding parties.
[13] Yue Chen, Yulong Zhang, Zhi Wang, Liangzhao Xia,
Chenfu Bao, and Tao Wei. Adaptive Android Kernel
References Live Patching. In USENIX Security, 2017.

[1] Martín Abadi, Mihai Budiu, Ulfar Erlingsson, and Jay [14] Andrei Costin, Jonas Zaddach, Aurélien Francillon, and
Ligatti. Control-Flow Integrity. In CCS, 2005. Davide Balzarotti. A large-scale analysis of the security
of embedded firmwares. In USENIX Security, 2014.
[2] Al Viro. iov_iter: saner checks on copyin/copyout, 2017.
[15] Samsung Knox Documentation. Real-time Ker-
URL: https://git.kernel.org/pub/scm/linux/
nel Protection (RKP), 2023. URL: https:
kernel/git/torvalds/linux.git/commit/?id=
//docs.samsungknox.com/admin/fundamentals/
09fc68dc66f7597bdc8898c991609a48f061bed5.
whitepaper/core-platform-security/real-
[3] Android. Kernel Control Flow Integrity, 2022. URL: time-kernel-protection/.
https://source.android.com/docs/security/ [16] Zeinab El-Rewini and Yousra Aafer. Dissecting residual
test/kcfi. apis in custom android roms. In CCS, 2021.
[4] Android. Overview, 2024. URL: https:// [17] Everphone. What is the average smartphone lifespan?,
source.android.com/docs/core/architecture/ 2023. URL: https://web.archive.org/web/
partitions. 20231123081219/https://everphone.com/en/
blog/smartphone-lifespan/.
[5] AppBrain. Top Android OS versions, 2023. accessed:
28.11.2023. URL: https://web.archive.org/web/ [18] Sadegh Farhang, Mehmet Bahadir Kirdan, Aron Laszka,
20231128122419/https://www.appbrain.com/ and Jens Grossklags. An empirical study of android
stats/top-android-sdk-versions. security bulletins in different vendors. In WWW, 2020.

[6] AppBrain. Top manufacturers, 2023. accessed: [19] Qian Feng, Rundong Zhou, Chengcheng Xu, Yao Cheng,
14.09.2023. URL: https://web.archive.org/web/ Brian Testa, and Heng Yin. Scalable Graph-based Bug
20230915054021/https://www.appbrain.com/ Search for Firmware Images. In CCS, 2016.
stats/top-manufacturers.
[20] Julien Gamba, Mohammed Rashed, Abbas Razagh-
[7] Brandon Azad. An iOS hacker tries panah, Juan Tapiador, and Narseo Vallina-Rodriguez.
Android, 2020. URL: https:// An analysis of pre-installed android software. In S&P,
googleprojectzero.blogspot.com/2020/12/ 2020.
an-ios-hacker-tries-android.html. [21] Daniel Gruss, Moritz Lipp, Michael Schwarz, Richard
Fellner, Clémentine Maurice, and Stefan Mangard.
[8] Brandon Azad. A survey of recent ios
KASLR is Dead: Long Live KASLR. In ESSoS, 2017.
kernel exploits, 2020. URL: https://
googleprojectzero.blogspot.com/2020/06/a- [22] Hemanth. Extractor of SpreadTrum firmware files with
survey-of-recent-ios-kernel-exploits.html. extension pac, 2023. URL: https://github.com/
HemanthJabalpuri/pacextractor.
[9] Ian Beer. Mind the Gap, 2022. URL: https://
googleprojectzero.blogspot.com/2022/11/. [23] Grant Hernandez, Dave Jing Tian, Anurag Swarnim Ya-
dav, Byron J. Williams, and Kevin R. B. Butler. Bigmac:
[10] Erik Buchanan, Ryan Roemer, Hovav Shacham, and fine-grained policy analysis of android firmware. In
Stefan Savage. When Good Instructions Go Bad: Gener- USENIX Security, 2020.
alizing Return-Oriented Programming to RISC. In ACM
Conference on Computer and Communications Security [24] Qinsheng Hou, Wenrui Diao, Yanhao Wang, Xiaofeng
(CCS), 2008. Liu, Song Liu, Lingyun Ying, Shanqing Guo, Yuanzhi
Li, Meining Nie, and Haixin Duan. Large-scale secu-
[11] Daming D Chen, Maverick Woo, David Brumley, and rity measurements on the android firmware ecosystem.
Manuel Egele. Towards automated dynamic analysis In International Conference on Software Engineering
for linux-based embedded firmware. In NDSS, 2016. (ICSE), 2022.

USENIX Association 33rd USENIX Security Symposium 4531

[25] Huawei. Emui 11.0 security technical white paper, 2020. [38] Lukas Maar, Stefan Gast, Martin Unterguggenberger,
URL: https://consumer.huawei.com/content/ Mathias Oberhuber, and Stefan Mangard. SLUBStick:
dam/huawei-cbg-site/common/campaign/ Arbitrary Memory Writes through Practical Software
privacy/whitepaper/emui_11.0_security_ Cross-Cache Attacks within the Linux Kernel. In
technical_white_paper_v1.0.pdf. USENIX Security, 2024.
[26] Zheyue Jiang, Yuan Zhang, Jun Xu, Xinqian Sun, [39] Lukas Maar, Martin Schwarzl, Fabian Rauscher, Daniel
Zhuang Liu, and Min Yang. Aem: Facilitating cross- Gruss, and Stefan Mangard. DOPE: DOmain Protection
version exploitability assessment of linux kernel vulner- Enforcement with PKS. In ACSAC, 2023.
abilities. In S&P, 2023.
[40] Marin. vmlinux-to-elf, 2023. URL: https://
[27] Zheyue Jiang, Yuan Zhang, Jun Xu, Qi Wen, Zhenghe github.com/marin-m/vmlinux-to-elf.
Wang, Xiaohan Zhang, Xinyu Xing, Min Yang, and
[41] Man Yue Mo. One day short of a full chain: Part 1 -
Zhemin Yang. PDiff: Semantic-Based Patch Presence
Android Kernel arbitrary code execution, 2021. URL:
Testing for Downstream Kernels. In CCS, 2020.
https://securitylab.github.com/research/
[28] Xingyu Jin and Richard Neal. The Art of Exploiting one_day_short_of_a_fullchain_android/.
UAF by Ret2bpf in Android Kernel, 2021. URL:
[42] Alexander Popov. Four Bytes of Power: Ex-
https://i.blackhat.com/EU-21/Wednesday/
ploiting CVE-2021-26708 in the Linux kernel,
EU-21-Jin-The-Art-of-Exploiting-UAF-by-
2021. URL: https://a13xp0p0v.github.io/2021/
Ret2bpf-in-Android-Kernel-wp.pdf.
02/09/CVE-2021-26708.html.
[29] Kailani R. Jones, Ting-Fang Yen, Sathya Chandran Sun-
[43] Andrea Possemato, Simone Aonzo, Davide Balzarotti,
daramurthy, and Alexandru G. Bardas. Deploying an-
and Yanick Fratantonio. Trust, but verify: A longitudinal
droid security updates: an extensive study involving
analysis of android oem compliance and customization.
manufacturers, carriers, and end users. In CCS, 2020.
In S&P, 2021.
[30] Max Kellermann. The Dirty Pipe Vulnerability, 2022. [44] Matteo Rizzo and Jann Horn. Prevent cross-
URL: https://dirtypipe.cm4all.com/. cache attacks in the SLUB allocator, 2023.
[31] Bjoern Kerler. oppo_decrypt_ozip, 2022. URL: https: URL: https://lore.kernel.org/linux-mm/
//github.com/bkerler/oppo_ozip_decrypt. 202309151425.2BE59091@keescook/T/.

[32] Bjoern Kerler. oppo_decrypt, 2023. URL: https:// [45] Seth Jenkins. Exploiting CVE-2022-42703 -
github.com/bkerler/oppo_decrypt. Bringing back the stack attack, 2022. URL:
https://googleprojectzero.blogspot.com/
[33] Zhenpeng Lin. How AUTOSLAB Changes 2022/12/exploiting-CVE-2022-42703-
the Memory Unsafety Game, 2021. URL: bringing-back-the-stack-attack.html.
https://grsecurity.net/how_autoslab_
changes_the_memory_unsafety_game. [46] Maddie Stone. Bad Binder: Android In-
The-Wild Exploit, 2019. URL: https:
[34] Zhenpeng Lin, Yuhang Wu, and Xinyu Xing. DirtyCred: //googleprojectzero.blogspot.com/2019/11/
Escalating Privilege in Linux Kernel. In ACM, 2022. bad-binder-android-in-wild-exploit.html.
[35] Zhenpeng Lin, Xinyu Xing, Zhaofeng Chen, and Kang [47] Maddie Stone. CONFIG_DEBUG_LIST=y, 2020.
Li. Bad io_uring: A New Era of Rooting for Android, URL: https://twitter.com/maddiestone/
2023. URL: https://i.blackhat.com/BH-US-23/ status/1245834936629616640?lang=de.
Presentations/US-23-Lin-bad_io_uring.pdf.
[48] Maddie Stone. Detection Deficit: A Year in Review
[36] Linux Kernel Driver DataBase. CON- of 0-days Used In-The-Wild in 2019, 2020. URL:
FIG_ARM64_UAO: Enable support for User Access https://googleprojectzero.blogspot.com/
Override (UAO), 2024. URL: https://cateee.net/ 2020/07/detection-deficit-year-in-review-
lkddb/web-lkddb/ARM64_UAO.html. of-0.html.
[37] Kangjie Lu, Marie-Therese Walter, David Pfaff, Ste- [49] Maddie Stone. 2022 0-day In-the-Wild
fan Nümberger, Wenke Lee, and Michael Backes. Un- Exploitation...so far, 2023. URL: https:
leashing Use-Before-Initialization Vulnerabilities in the //googleprojectzero.blogspot.com/2022/
Linux Kernel Using Targeted Stack Spraying. In NDSS, 06/2022-0-day-in-wild-exploitationso-
2017. far.html.

4532 33rd USENIX Security Symposium USENIX Association

[50] Maddie Stone. The Ups and Downs of [62] Jun Yao. arm64/mm: move
0-days: A Year in Review of 0-days Ex- {idmap_pg_dir,tramp_pg_dir,swapper_pg_dir}
ploited In-the-Wild in 2022, 2023. URL: to .rodata section, 2018. URL: https:
https://security.googleblog.com/2023/07/ //patchwork.kernel.org/project/linux-
the-ups-and-downs-of-0-days-year-in.html. hardening/patch/20180620085755.20045-2-
[email protected]/.
[51] Superr. splituapp, 2019. URL: https://github.com/
superr/splituapp. [63] Wang Yong. KSMA: Breaking Android kernel
isolation and Rooting with ARM MMU features, 2018.
[52] Thomas Sutter and Bernhard Tellenbach. Firmware- URL: https://i.blackhat.com/briefings/asia/
droid: Towards automated static analysis of pre-installed 2018/asia-18-WANG-KSMA-Breaking-Android-
android apps. In MOBILESoft, 2023. kernel-isolation-and-Rooting-with-ARM-
MMU-features.pdf.
[53] Seyed Mohammadjavad Seyed Talebi, Zhihao Yao,
Ardalan Amiri Sani, Zhiyun Qian, and Daniel Austin. [64] Ruotong Yu, Francesca Del Nin, Yuchen Zhang, Shan
Undo workarounds for kernel bugs. In USENIX Security, Huang, Pallavi Kaliyar, Sarah Zakto, Mauro Conti, Geor-
2021. gios Portokalidis, and Jun Xu. Building embedded sys-
tems like it’s 1996. In NDSS, 2022.
[54] USA Today. How long before a phone is
outdated? Here’s how to find your smart- [65] Kyle Zeng, Yueqi Chen, Haehyun Cho, Xinyu Xing,
phone’s expiration date, 2023. URL: https: Adam Doupé, Yan Shoshitaishvili, and Tiffany Bao.
//web.archive.org/web/20231022153016/ Playing for K(H)eaps: Understanding and Improving
https://eu.usatoday.com/story/tech/ Linux Kernel Exploit Reliability. In USENIX Security,
columnist/komando/2023/10/22/how-to-find- 2022.
smartphone-expiration-date/71255625007/. [66] Hang Zhang and Zhiyun Qian. Precise and Accurate
[55] Vasya. payload dumper, 2023. URL: https:// Patch Presence Test for Binaries. In USENIX Security,
github.com/vm03/payload_dumper. 2018.
[67] Zheng Zhang, Hang Zhang, Zhiyun Qian, and Billy Lau.
[56] Zicheng Wang, Yueqi Chen, and Qingkai Zeng. PET:
An investigation of the android kernel patch ecosystem.
Prevent Discovered Errors from Being Triggered in the
In USENIX Security, 2021.
Linux Kernel. In USENIX Security, 2023.
[68] Xiaochen Zou, Yu Hao, Zheng Zhang, Juefei Pu, Weit-
[57] Daoyuan Wu, Debin Gao, Eric K. T. Cheng, Yichen eng Chen, and Zhiyun Qian. Syzbridge: Bridging the
Cao, Jintao Jiang, and Robert H. Deng. Towards under- gap in exploitability assessment of linux kernel bugs in
standing android system vulnerabilities: Techniques and the linux ecosystem. In NDSS, 2024.
insights. In AsiaCCS, 2019.

[58] Nicolas Wu. Dirty Pagetable: A Novel Exploitation

Technique To Rule Linux Kernel, 2023. URL:
https://yanglingxi1993.github.io/dirty_ A Detailed Statistics
pagetable/dirty_pagetable.html.
A.1 Detailed Defense Detection of Kernels
[59] Wei Wu, Yueqi Chen, Xinyu Xing, and Wei Zou. KE-
Table 3 illustrates the comprehensive list of how we assess
PLER: Facilitating Control-flow Hijacking Primitive
the state of our identified defense mechanisms. We follow
Evaluation for Linux Kernel Vulnerabilities. In USENIX
the procedure to identify symbols of globally reachable func-
Security, 2019.
tions within the kallsyms file. This file contains all globally
[60] Wen Xu, Juanru Li, Junliang Shu, Wenbo Yang, Tianyi reachable functions and variable symbols used in the kernel
Xie, Yuanyuan Zhang, and Dawu Gu. From collision to binary, e.g., marked with EXPORT_SYMBOL. For instance, the
exploitation: Unleashing use-after-free vulnerabilities presence of __list_add_valid in kallsyms indicates the
in linux kernel. In CCS, 2015. status of the CONFIG_DEBUG_LIST. As another example, the
symbol cache_random_seq_create indicates the presence
[61] Zhengzi Xu, Yulong Zhang, Longri Zheng, Liangzhao of CONFIG_SLAB_FREELIST_RANDOM. A similar assessment
Xia, Chenfu Bao, Zhi Wang, and Yang Liu. Automatic stands true for detecting the other defenses. Additionally, to
Hot Patch Generation for Android Kernels. In USENIX identifying symbols kallsyms, our approach also detects de-
Security, 2020. fense mechanisms which do not contain globally reachable

USENIX Association 33rd USENIX Security Symposium 4533

Table 3: Symbols and used additional information for our defense detection approach. The defense feature ✩ is enabled if this
symbol (e.g., globally visible function or variable) is present within the kallsyms containing all kernel symbols.
Defense Feature Kernel Executable Present within kallsyms✩ Information
__list_add_valid, __list_del_entry_valid ≥v3.18
CONFIG_DEBUG_LIST
__list_add, __list_del_entry <v3.18
CONFIG_CFI_CLANG cfi_module_add, cfi_module_remove
___bpf_prog_run ≥v4.14
CONFIG_BPF_JIT_ALWAYS_ON
__bpf_prog_run <v4.14
kmalloc-cg-* available for ≥v5.13
CONFIG_INIT_ON_ALLOC_DEFAULT_ON init_on_alloc
CONFIG_ARM64_UAO uao_thread_switch, cpu_enable_uao no addr_limit for ≥v5.11
CONFIG_SLAB_FREELIST_HARDENED get_random_long called within __kmem_cache_create
KSMA Protection swapper_pg_dir, tramp_pg_dir swapper_pgdir_lock, swapper_pg_dir, tramp_pg_dir *_pg_dir mapped as read-only
Samsung RKP rkp_init only for Samsung devices
CONFIG_RANDOMIZE_BASE module_alloc_base, kaslr_early_init
named as CONFIG_DEBUG_RODATA for <v4.14;
CONFIG_STRICT_KERNEL_RWX set_debug_rodata, mark_readonly, mark_rodata_ro
on v3.10 only for 32 bit systems
CONFIG_ARM64_PAN cpu_enable_uao
reserved_ttbr0 <v5.4; available for ≥v4.10
CONFIG_ARM64_SW_TTBR0_PAN "emulated: Privileged Access Never (PAN) \
≥v4.19
using TTBR0_EL1 switching"
CONFIG_SLAB_FREELIST_RANDOM cache_random_seq_create, cache_random_seq_destroy
CONFIG_UNMAP_KERNEL_AT_EL0 tramp_pg_dir

Table 4: Statistical results of firmware extraction and kernel Table 5: Included defenses averaged over all firmwares for
code collection. each vendor. ✶ inidcates that it is ineffective while ✩ indicates
that it is ineffective for kernels <v5.11.
Vendors Firmware Extraction Kernel Code
#devices #available #extracted #collected Vendor ² / ⋔ ✩ ® ✶ ¥ © ç  Ó 
Samsung 197 190 164 654 Samsung 60 49 26 8 63 96 25 5 84 100 91 27 16 39
Xiaomi 278 151 143 188 Xiaomi 89 94 74 0 93 98 10 1 97 100 97 10 83
Oppo 229 145 114 29 Oppo 50 49 19 0 44 95 37 13 91 100 95 49 14
Vivo 69 65 27 5 67 96 44 22 95 98 88 73 22
Vivo 307 178 144 30 Realme 91 91 34 2 89 100 36 22 100 100 99 47 44
Realme 307 137 135 135 Huawei 15 18 67 0 20 92 12 13 97 100 79 87 14 62
Huawei 182 121 119 218 Motorola 62 58 34 1 59 90 44 29 89 100 79 58 31
Motorola 115 112 104 246 Google 88 88 100 8 88 100 65 65 100 100 100 77 65
Oneplus 83 83 52 10 83 100 69 55 100 100 100 90 55
Google 26 26 26 9 Fairphone 67 67 33 0 67 100 33 33 100 100 100 67 33
OnePlus 54 46 42 21 ² CONFIG_DEBUG_LIST / CONFIG_BPF_JIT_ALWAYS_ON ⋔ CONFIG_CFI_CLANG kmalloc-cg-*
Fairphone 3 3 3 3 CONFIG_INIT_ON_ALLOC_DEFAULT_ON  CONFIG_ARM64_UAO ® CONFIG_SLAB_FREELIST_HARDENED
KSMA protection CONFIG_RANDOMIZE_BASE ¥ CONFIG_STRICT_KERNEL_RWX
Total 1698 1109 994 1533
© CONFIG_ARM64_(SW_TTBR0_)PAN ç CONFIG_SLAB_FREELIST_RANDOM  CONFIG_UNMAP_KERNEL_AT_EL0
Ó Samsung RKP  Huawei HKIP

symbols. For instance, CONFIG_SLAB_FREELIST_HARDENED Table 6: ✓ indicates defenses available for mainline Android
only includes inline functions and member variables. To de- kernel from v3.10 to v6.1, while ✗ indicates that the defense
tect the presence of this defense, our approach analyzes the is not required for the specific version.
kernel binary, more specifically, the function where these in- Kernel ² / ⋔  ® ¥ © ç 
line calls are executed, e.g., get_random_long within func- v3.10 ✓ ✗ ✓
v3.18 ✓ ✓ ✓ ✓ ✓ ✓
tion kmem_cache_open. Executing the call indicates the pres- v4.4 ✓ ✓ ✓ ✓ ✓ ✓ ✓
ence of this defense. To detect the presence of the KSMA pro- v4.9 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
v4.14 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
tection, swapper_pg_dir and tramp_pg_dir must also be v4.19 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
mapped read-only. For instance, these pages might be mapped v5.4 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
v5.10 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
between __start_rodata and __init_begin. v5.15 ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓
v6.1 ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓
² CONFIG_DEBUG_LIST / CONFIG_BPF_JIT_ALWAYS_ON ⋔ CONFIG_CFI_CLANG kmalloc-cg-*
A.2 Statistical Results of Firmware Extraction CONFIG_INIT_ON_ALLOC_DEFAULT_ON  CONFIG_ARM64_UAO ® CONFIG_SLAB_FREELIST_HARDENED
KSMA protection CONFIG_RANDOMIZE_BASE ¥ CONFIG_STRICT_KERNEL_RWX
© CONFIG_ARM64_(SW_TTBR0_)PAN ç CONFIG_SLAB_FREELIST_RANDOM  CONFIG_UNMAP_KERNEL_AT_EL0
Table 4 illustrates the extractable firmwares. Our success rate
of 58.5 % (with a collection and extraction rate of 65.3 % Table 7: The susceptibility reduction (i.e., Susc Reduc)
and 89.6 %) from produced devices to extractable firmwares against one-days of high-end to low-end devices.
aligns with prior work [11, 14, 64]. The two main reasons for Vendor Low-End High-End Susc Reduc
extraction failure were that our approach did not recognize Devices Susc Devices Susc in %
the correct format or that part of the firmware was corrupted. Samsung Galaxy A(1,2,3,5)4 5.5 Galaxy S23.* 4.5 18.2
Xiaomi Redmi 12.* 12.0 13T.* 12.0 0.0
Oppo A(3,9)8 12.0 Find X2.* 10.0 16.7
Vivo Y(100,27) 11.0 X100.* 4.0 63.6
Realme C(33,53,55) 10.7 Neo 5.* 10.0 6.2
Huawei Nova 11.* 15.5 P60.* 10.0 35.5
Motorola G(1,5,8)4.* 10.7 Edge 40.* 8.5 20.3
OnePlus Nord 3.* 10.0 11.* 7.0 30.0
Mean 23.8

4534 33rd USENIX Security Symposium USENIX Association