RangeSanitizer: Detecting Memory Errors with Efficient Range Checks

The Doom of Device Drivers: Your Android Device (Most Likely) has N-Day Kernel Vulnerabilities

Speakers: Lukas Maar (Graz University of Technology); Florian Draschbacher (Graz University of Technology and A-SIT Austria); Lorenz Schumm (Graz University of Technology); Ernesto Martínez García (Graz University of Technology); Stefan Mangard (Graz University of Technology)

Conference: USENIX Security

Paper PDF: https://www.usenix.org/system/files/usenixsecurity25-maar-doom.pdf

Overview

This groundbreaking paper, "The Doom of Device Drivers: Your Android Device (Most Likely) has N-Day Kernel Vulnerabilities," presented by Lukas Maar and his colleagues from Graz University of Technology, critically re-evaluates the security posture of Android devices. Historically, sophisticated Android attacks necessitated complex exploit chains, often requiring initial privilege escalation within user-space before targeting the kernel. Recent trends, however, have seen attackers directly targeting kernel GPU drivers from untrusted applications, bypassing the need for these intermediate privilege pivots. While significant industry efforts, particularly from Google, have focused on hardening GPU drivers, the broader landscape of kernel drivers accessible to untrusted apps has remained largely underexplored at scale.

The research delivers a comprehensive, large-scale analysis of kernel drivers accessible to untrusted applications across a representative set of 131 Android devices. Employing a mostly automated approach to extract access control policies from device firmwares, the team identified a significantly expanded attack surface beyond GPUs, encompassing 11 additional driver types. Crucially, by reconstructing 50 known vulnerabilities from public information and performing a subsequent patch inclusion analysis, the paper reveals a pervasive problem: over 59% of the analyzed devices were vulnerable to highly critical n-day kernel exploits at the time of analysis, or for extended periods, due to unapplied patches.

This work not only uncovers novel insights into the disparity in patch timelines and vendor practices but also demonstrates that malicious actors can exploit these readily available n-day vulnerabilities, circumventing the resource-intensive development of zero-day exploits. The findings underscore an urgent need for concerted action to improve Android's overall security, shifting focus beyond GPU drivers to the broader array of accessible kernel components and addressing critical shortcomings in patch management across the Android ecosystem.

Background

To understand the severity of the findings, it's essential to contextualize the terminology and the evolving landscape of Android security. A zero-day vulnerability is an unknown security flaw for which no public patch exists, making it highly valuable to attackers. Conversely, an n-day vulnerability is a known security issue with existing public patches or mitigations that have not yet been applied to a target system. A full exploit chain typically involves multiple stages, progressing from an initial code execution in an untrusted context (e.g., a browser or messenger app) to ultimately compromising the device's kernel. Exploit primitives are basic capabilities gained from exploiting a vulnerability (e.g., an out-of-bounds write), which can then be converted into more impactful outcomes like arbitrary read/write using exploit techniques.

Historically, full Android device compromises were intricate, often requiring attackers to pivot through elevated processes before reaching the kernel. For instance, a 2022 Google Project Zero attack started with remote code execution in Chrome (an untrusted context), then exploited a system service vulnerability to gain system privileges, and finally targeted a kernel sound driver for arbitrary read/write, leading to full device compromise. This multi-stage approach was necessary because Android tightly restricts the kernel attack surface exposed to most untrusted applications.

However, recent years have seen a strategic shift. Experts highlighted that GPU drivers are directly accessible from untrusted contexts, allowing full-chain exploits to bypass intermediate privilege escalation by targeting the GPU directly. This made GPU drivers prime targets, with Google's 2023 annual review attributing 4 of 5 device compromises to GPU driver vulnerabilities. In response, Google has heavily prioritized GPU security, collaborating with the Android Red Team and ARM to enhance detection and mitigation. This focused effort raised the critical question addressed by this paper: are GPUs the only attractive targets for malicious actors, or do other kernel components pose similar, yet unaddressed, risks?

Android's security model relies heavily on a combination of Linux's user-group-based Discretionary Access Control (DAC) and Security-Enhanced Linux (SELinux)'s Mandatory Access Control (MAC) policies. DAC isolates applications from each other by running each app under its own Linux user. SELinux, integrated into the Linux Security Module (LSM) framework, enforces fine-grained access control decisions based on a default-denial principle. The untrusted_app security context is assigned to third-party applications, strictly limiting their interaction with sensitive system resources, including most of the kernel and its drivers. Other contexts, like system_app, exist for privileged applications.

A significant initiative to address kernel fragmentation and update delays was Google's Generic Kernel Image (GKI) project. Introduced with Android 11 (GKI 1.0) and mandated for kernels 5.10+ (GKI 2.0), GKI aims to standardize the kernel, maintained and built by Google, which receives long-term stable changes and critical bug fixes. To compensate for device customization, OEMs now rely on introducing device-specific functionalities via kernel modules, which are loaded dynamically. While GKI was intended to resolve kernel fragmentation and improve security update timeliness, this research reveals that these OEM-specific kernel modules introduce new challenges, particularly regarding the timely application of security patches.

Key Findings

The paper presents several crucial findings that significantly alter the understanding of Android's kernel security:

• Widespread N-Day Vulnerability Prevalence: A staggering 59.1% of the analyzed Android devices were found to be susceptible to at least one highly critical n-day kernel vulnerability (e.g., Use-After-Free, Out-Of-Bounds writes) at the time of analysis. Furthermore, 61.4% of devices were affected by at least one n-day vulnerability of any severity. This indicates a pervasive and unaddressed security risk across the Android ecosystem.
• Expanded Kernel Attack Surface Beyond GPUs: The research identifies a significant kernel attack surface accessible from untrusted untrusted_app contexts that extends far beyond GPU drivers. Through comprehensive analysis of 493 firmwares, 11 additional types of kernel drivers were found to be accessible, including those for the Digital Signal Processor (DSP), JPEG decoding accelerator, Artificial Intelligence (AI) coprocessor, Neural Processing Unit (NPU), Audio, GPU Extension, Monitor, Memory, and Camera.
• 50 Reconstructed N-Day Vulnerabilities: The study successfully reconstructed 50 known vulnerabilities across 7 of the 11 identified driver types from public git repositories and bug reports over the last four years. These vulnerabilities were categorized by their exploit capabilities: 16 Use-After-Free (UAF) or Double-Free (DF), 9 Out-Of-Bounds (OOB) writes, 11 "Others" (including Uninitialized Variables, Null Pointer Dereferences, and Denial of Service), and 14 Information Disclosure (ID) (including Out-Of-Bounds reads). UAF, DF, and OOB writes are particularly critical as they serve as powerful initial exploit primitives.
• Significant and Inconsistent Patch Delays: The analysis reveals substantial delays in the integration of security patches, with some vulnerabilities remaining unpatched for up to 830 days. Patch timelines vary widely across OEMs, ODMs, and vulnerability types. Specifically, MediaTek-based devices were found to be more than two times slower to receive patches than Qualcomm-based devices. While OOB issues experienced the fastest patch inclusion, followed by UAF and ID, even critical vulnerabilities often remained unaddressed for over a year.
• OEMs Prioritize New Devices Over Updates: A concerning trend observed is that OEMs primarily address security flaws by releasing new devices with updated kernel driver versions rather than issuing firmware updates for existing susceptible devices. This practice leaves a large installed base of older, yet still recent, devices vulnerable for extended periods.
• High Reusability of N-Day Exploits: The research demonstrates that Proof-of-Concept (PoC) exploits for these n-day vulnerabilities, particularly in ODM-maintained drivers like the DSP driver, are highly versatile and can be reused across different OEMs and device models sharing the same chipset. This significantly lowers the barrier for malicious actors.
• Correlation of Vulnerabilities: Devices found susceptible to one n-day vulnerability are highly likely to be susceptible to multiple. For example, 71.4% of Xiaomi devices had at least one n-day vulnerability, and 49% had three or more.
• Attacker's Advantage: The widespread availability of unpatched n-day vulnerabilities in directly accessible kernel drivers provides an attractive pathway for malicious actors, reducing their reliance on the time-consuming and resource-intensive discovery of complex zero-day vulnerabilities. This aligns with real-world Android exploitation trends.

Technical Deep Dive

The core of this research lies in its meticulous, multi-stage methodology for identifying accessible kernel drivers, reconstructing n-day vulnerabilities, and analyzing patch inclusion across a vast dataset of Android firmwares.

The study began by collecting and extracting 493 firmwares from 131 Android devices across 7 major OEM vendors (Samsung, Xiaomi, Asus, Realme, OnePlus, Oppo, Vivo) and 3 ODM vendors (Qualcomm, MediaTek, Samsung), collectively representing over 75% of the Android market share. Firmware collection was mostly automated using a Python Selenium web crawler, with manual intervention for captcha-protected sources. The focus was on recent devices (October 2022 to December 2024), as these are more likely to receive security updates.

Attack Surface Analysis of Android Kernels

To determine the kernel attack surface accessible from untrusted_app contexts, the researchers developed a mostly automated approach that combines static analysis of SELinux policies and Linux permission settings with kernel driver matching.

1. Analyzing SELinux Policies:

• The process extracts two critical SELinux configuration files: precompiled_sepolicy (defining allowed access of SELinux contexts to specific domains) and vendor_file_contexts (assigning file paths to domains).
• The official SELinux policy query tool, sesearch, is then used to identify access control rules for character devices (virtual files typically mounted in /dev/, interacted with via open and ioctl syscalls) and ProcFS files (virtual files in /proc/, created using proc_create).
• For character devices, sesearch queries identify which chr_file domains are accessible to untrusted_app contexts. vendor_file_contexts is then used to resolve these domains to their actual mounting points (e.g., vendor_qdsp_device maps to /dev/adsprpc-smd).
• For ProcFS files, domain names directly contain the path (e.g., proc_ged refers to /proc/ged).
• Pivoting Contexts: The analysis also accounts for scenarios where untrusted_app might not have direct open permissions but can legally "pivot" to a more privileged context (like platform_app or vendor_dspservice) that does have such permissions. This is achieved via Android's Binder IPC (Inter-Process Communication) and shared file descriptors, allowing the privileged context to open a device and then share its reference with the untrusted app.

1. Analyzing Linux Permission Settings:

• The approach extracts all Run Control (RC) scripts (from /etc/ or /etc/init) executed during device startup.
• These scripts often contain chmod and chown commands that define user-group-based read, write, and execute permissions for files and devices.
• A character device is deemed accessible if both its RC permissions allow access to unprivileged "others" users and a SELinux policy rule permits access from unprivileged contexts.

1. Matching Kernel Drivers:

• Since GKI 2.0, OEM-specific kernel drivers are typically loaded as external modules, found either in the vendor_dlkm partition or compressed within a ramdisk in the vendor_boot partition.
• The process involves extracting these modules (e.g., using binwalk for ramdisks).
• Device nodes (in /dev/ or /proc/) are then matched to their corresponding kernel modules. For /dev/ nodes, file names are matched against strings in kernel modules, followed by manual verification with source code. For /proc/ nodes, driver modules are scanned for the file name and the proc_create_file symbol, with manual inspection to confirm accessibility.
• Finally, it's verified that matched modules appear in modules.load, ensuring they are loaded at startup.

This large-scale static analysis identified 11 kernel drivers, beyond GPUs, accessible to untrusted contexts, including apusys.ko (AI), frpc-adsprpc.ko (DSP), npu.ko (NPU), xlogchar.ko (Audio), ged.ko (GPU Extension), mtk_perf_ioctl.ko (Monitor), jpeg-driver.ko (JPEG), trusted_mem.ko (Memory), mi_log.ko (Monitor), and camera.ko (Camera). Dynamic testing on a representative subset of 15 devices from 4 OEMs and 3 ODMs confirmed the static analysis results, with an unprivileged Android app attempting syscalls like open, read, write, and ioctl on identified paths.

Analysis of N-Day Vulnerabilities

Leveraging Android's open-source policy (GPLv2 for kernel modifications), the researchers performed a history tree search on publicly available git repositories (e.g., Qualcomm's dsp-kernel.git) and bug reports (e.g., Google Project Zero's issue tracker).

• Keyword Filtering: Commit messages from 2020 to December 2024 were automatically filtered using security-related keywords such as "bug," "use-after-free," and "out-of-bounds."
• Manual Verification: The filtered commits were then manually verified to confirm they addressed security-critical bugs. For instance, commit 2466bcf in dsp/adsprpc.c was identified as fixing an Out-Of-Bounds (OOB) write vulnerability by adding a VERIFY check to ensure chan->sesscount remains within NUM_SESSIONS. Another example, commit 3a1e7d8, addressed a Use-After-Free (UAF) vulnerability in fastrpc_mmap that could lead to a Double-Free (DF).
• Vulnerability Classification: The 50 identified vulnerabilities were categorized based on their exploit capabilities: UAF (16), OOB (9), Others (11 - Uninitialized Variables, Null Pointer Dereferences, Denial of Service), and ID (14 - Out-Of-Bounds Read, Information Disclosure). The paper argues that any accessible vulnerability falling into categories known to facilitate system compromise (UAF, DF, OOB writes) should be classified as critical, advocating for prompt patching rather than delaying for full exploitability proofs.

Detecting N-Day Patches in Kernel Drivers

A semi-automated approach was developed to detect the presence or absence of patches for 21 selected n-day vulnerabilities (from the DSP, JPEG, and GED kernel drivers) across the 493 firmware versions. This involved:

• Symbol-Based Detection: Identifying new global functions, variables, or unique string artifacts (e.g., specific warning messages like ADSPRPC_WARN) introduced by a patch in the compiled target driver. Manual verification is used to rule out false negatives due to kernel driver configurability or code evolution.
• Control-Flow Analysis: Performing differential analysis of assembly code between sequential driver versions. For versions with assembly modifications, Ghidra decompilation is used to identify changes in program logic, such as new conditional checks.

This methodology ensures robust patch detection, even though the full automation of such a complex task remains a challenge for future work (e.g., adapting tools like PDiff or Fiber). The analysis revealed that 59.1% of devices were vulnerable to highly critical n-day exploits, and patch delays could exceed 830 days.

Demo / Proof of Concept

To validate the real-world exploitability and reachability of vulnerable code, the researchers performed dynamic testing by triggering a representative subset of n-day vulnerabilities on a physical Android device. While developing full end-to-end exploits is a highly complex and time-consuming task, even for experts, the team focused on demonstrating that five selected vulnerabilities from the frpc-adsprpc.ko DSP driver could be reliably triggered.

The chosen vulnerabilities represented a range of bug classes: one Out-Of-Bounds (OOB) read, three Use-After-Free (UAF) issues, and one Information Disclosure (ID). The testing was conducted on a rooted Samsung Galaxy S23 equipped with the Qualcomm SM8550-AC Snapdragon 8 Gen 2 chipset. To overcome the Enhanced Read-Only File System (EROFS), which prevents direct modification of kernel driver partitions, the researchers flashed TWRP/RO2RW images and remounted the vendor_dlkm partition as writable. This allowed them to replace the frpc-adsprpc.ko driver with test versions.

Crucially, the team tested driver versions from 13 Android phones across three major OEMs (Samsung, Xiaomi, and Asus), spanning multiple timestamps. These devices all used the same chipset as the test device, ensuring compatibility. They manually confirmed that substituting a driver module from another OEM with the same chipset did not alter its functionality, streamlining the testing process.

The observable effects of triggering these vulnerabilities were clear: the UAF issues and OOB read caused device crashes, while the information disclosure vulnerability successfully leaked a kernel pointer. Publicly available Proof-of-Concepts (PoCs) were used where possible, and new ones were developed for specific cases.

The results of this dynamic testing were stark:

• On Samsung devices, the tested vulnerabilities remained n-day exploitable for periods ranging from 0 to 7 months, depending on the specific vulnerability. The October 2024 firmware release for the Galaxy S23 was the first to include all five patches.
• In stark contrast, for all tested Xiaomi and Asus devices, multiple vulnerabilities remained exploitable even in their most recent firmware releases (November and December 2024). Specifically, all tested Xiaomi and Asus models were vulnerable to at least two of the PoCs, with some vulnerable to four. Patch delays for these devices varied from 0 to over 9 months, depending on the device and vulnerability.

This dynamic validation not only confirmed the static analysis results but also powerfully demonstrated that PoCs for n-day vulnerabilities in ODM-maintained drivers can indeed be reused across different OEMs and timeframes, significantly lowering the bar for attackers.

Defensive Implications

The findings of this research carry profound defensive implications for the entire Android ecosystem, demanding urgent and comprehensive action from OEMs, ODMs, and Google.

First and foremost, there is an urgent need for improved patch management. The pervasive presence of highly critical n-day kernel vulnerabilities, coupled with significant patch delays (up to 830 days), indicates a systemic failure in the current update process. OEMs and ODMs must prioritize the timely application of known security fixes to all supported devices, not just the newest models. The practice of addressing vulnerabilities primarily through the release of new devices, rather than through updates to existing ones, is unsustainable and leaves billions of users exposed.

Secondly, the focus of Android security efforts must expand beyond GPU drivers. While Google’s concentrated efforts on GPU security are commendable, this research clearly demonstrates that the kernel attack surface accessible to untrusted apps is far broader, encompassing 11 other types of drivers (DSP, JPEG, AI, NPU, etc.). These less-explored components now represent critical weak links that malicious actors can exploit. Security research, vulnerability detection, and hardening efforts need to be extended to cover this entire spectrum of accessible kernel drivers.

Thirdly, the disparity in patch timelines across ODMs is a significant concern. The observation that MediaTek-based devices are more than twice as slow to receive patches compared to Qualcomm-based devices highlights a crucial vulnerability in the supply chain. Google, as the platform owner, needs to exert greater influence and establish stricter enforcement mechanisms to ensure consistent and timely patch propagation from all chipset vendors. This includes setting clear service-level agreements for patch delivery.

Furthermore, vendors should re-evaluate their criteria for classifying and prioritizing vulnerabilities. The paper argues that if an accessible vulnerability falls into a category known to facilitate system compromise (such as Use-After-Free, Double-Free, or Out-Of-Bounds writes), it should be treated as critical and patched promptly, even without a demonstrated end-to-end exploit. The rapid evolution of exploit techniques means that seemingly "low-risk" primitives can quickly become critical. Prioritizing patch integration over extensive exploitability analysis would significantly reduce the window of opportunity for attackers.

Finally, there is a need for continuous monitoring and verification of patch inclusion. The semi-automated approach developed in this paper could be adapted and scaled by vendors to proactively identify unpatched n-day vulnerabilities across their device lineups. This would enable a more data-driven and responsive approach to security updates, ensuring that patches are not just released but effectively deployed and verified on end-user devices. Ultimately, the security of Android devices is only as strong as their weakest link, and this research unequivocally points to neglected kernel device drivers as that critical point of failure.

Key Takeaways

• Android's kernel attack surface accessible to untrusted applications is significantly larger than previously recognized, extending beyond GPU drivers to encompass at least 11 other critical driver types like DSP, JPEG, and AI coprocessors.
• A pervasive threat of n-day kernel vulnerabilities exists, with over 59% of recent Android devices susceptible to highly critical issues that can be exploited by malicious actors without the need for complex zero-day development.
• OEMs and ODMs exhibit severe and inconsistent patch delays, often exceeding one year, and frequently address vulnerabilities by releasing new devices rather than providing timely updates for existing ones. MediaTek-based devices, in particular, show significantly longer patch delays.
• Proof-of-concept exploits for these n-day kernel vulnerabilities are highly reusable across various OEMs and device models sharing the same chipset, making them attractive and accessible targets for attackers.
• Urgent action is required from all stakeholders to improve patch management, expand security focus beyond GPUs to all accessible kernel drivers, and ensure consistent, timely security updates for the entire Android device ecosystem to mitigate these widespread n-day threats.

About the Speaker(s)

The research presented in "The Doom of Device Drivers: Your Android Device (Most Likely) has N-Day Kernel Vulnerabilities" was authored by a team of researchers from Graz University of Technology and A-SIT Austria. The primary author is Lukas Maar, alongside Florian Draschbacher, who is affiliated with both Graz University of Technology and A-SIT Austria. Other contributing authors include Lorenz Schumm, Ernesto Martínez García, and Stefan Mangard, all from Graz University of Technology. Their collective work focuses on system security, particularly in mobile platforms like Android, with a keen interest in identifying and mitigating kernel-level vulnerabilities and understanding the broader implications of patch management and vendor practices in the mobile security landscape.