OEMpocalypse: Unprivileged Android App to Root via OEM Code

Gaining root privileges on a modern Android device from an unprivileged untrusted_app context is a formidable challenge. The Android security model, built on layers of Unix Discretionary Access Control (DAC), SELinux Mandatory Access Control (MAC), and seccomp system call filtering, severely limits an app's direct interaction with the kernel. This intricate sandboxing ensures that most of the kernel and its driver stack are unreachable without first escalating privileges to a more permissive domain.

Yet, the pursuit of unprivileged-to-root exploits continues, driven by the desire for maximum reliability, portability, and universality. The ideal “one exploit to rule them all” would succeed near-100% on any device, with minimal adjustments across kernel versions, OEMs, chipsets, or specific models. This article delves into a novel strategy, dubbed "OEMpocalypse," which specifically targets Original Equipment Manufacturer (OEM) code to achieve root on devices from major players like Samsung, Xiaomi, and Oppo/OnePlus/Realme.

The Landscape of Android Kernel Exploitation

Before exploring the OEMpocalypse strategy, it's essential to understand the existing approaches and their trade-offs. The kernel attack surface available to an untrusted_app includes the core Linux syscall surface (memory management, VFS, networking, Binder), shared-memory and DMA-BUF heaps, and GPU drivers. Critically, this surface can be categorized by the code's origin: generic Linux, chipset-specific, or OEM-specific.

Generic Linux Kernel Vulnerabilities

Bugs in the upstream Linux kernel or Android Common Kernel (ACK) are attractive because they are OEM- and chipset-agnostic. Theoretically, a single exploit could work across different manufacturers on the same kernel branch. Impressive work, such as the IonStack research, demonstrates the potential reach of memory-management bugs in generic code.

However, weaponizing these bugs reliably is a significant engineering challenge. The accessible core Linux code is heavily audited, meaning exploitable primitives are often constrained slab-level UAFs, limited Out-Of-Bounds (OOB) writes, or tight race conditions. Transforming these into root access typically demands complex heap grooming, cross-cache techniques, and information leaks, all of which are sensitive to system variations.

Furthermore, an exploit must remain stable across three axes: kernel version (e.g., 5.15 to 6.12), OEM customizations (e.g., Samsung's RKP/KDP, mem-cg configuration), and individual device hardware (e.g., RAM size, core count impacting allocator behavior). These factors often lead to a matrix of special cases, requiring continuous maintenance.

Chipset Drivers Reachable from untrusted_app

Chipset drivers, particularly those for GPUs (Mali, Adreno KGSL, PowerVR) and DSPs/NPUs, represent a significant portion of public Android Local Privilege Escalation (LPE) work. These drivers are often exposed directly to unprivileged apps for performance reasons. Bugs here, like those in Mali GPUs or Qualcomm's adsprpc DSP driver, are generally excellent to work with.

Structurally, these drivers manage physical pages and device-side page tables (GPU/DSP) on behalf of userspace. Consequently, a bug often yields a page Use-After-Free (UAF) or an arbitrary physical mapping directly. Mistakes in managing page lifetimes – such as releasing a page while a device mapping still points to it – directly result in page-level primitives, a far more straightforward starting point than a slab-level UAF in generic Linux code.

Device coverage, however, varies. Shared Qualcomm code might span many Snapdragon generations and multiple OEMs, while bugs tied to a specific Mali IP block or MediaTek driver revision cover a much smaller segment. Crucially, a single OEM often ships devices with different chipsets (e.g., Samsung's Exynos and Snapdragon flagships), meaning a chipset bug rarely covers an OEM's entire product line.

The OEMpocalypse Strategy: Targeting OEM Code

The OEMpocalypse strategy shifts focus to kernel drivers and userspace services developed by OEMs themselves – code integral to One UI (Samsung), HyperOS (Xiaomi), or ColorOS (Oppo/OnePlus/Realme). This OEM-specific code is tied to the OEM's software layer, not the underlying chipset, offering a distinct coverage advantage: a single bug can, in principle, affect every device running that OEM's affected software component, regardless of its internal silicon.

The core idea is a two-stage attack: first, escape the untrusted_app sandbox into a more privileged OEM-owned process, and then, from that privileged context, exploit a page UAF in an OEM kernel driver.

Stage 1: Escaping the Sandbox

Android's isolation isn't absolute; apps and services need to communicate. OEMs augment AOSP with numerous custom apps, services, and native daemons, each exposing Inter-Process Communication (IPC) endpoints (Binder, intents, content providers, local sockets). These endpoints are potential avenues for privilege escalation.

Stage 1 involves exploiting a logic flaw in one of these OEM IPC handlers – perhaps a missing caller check, an improperly exported component, or an unvalidated file path. Such a bug, living entirely in OEM userspace, allows an attacker to move from untrusted_app into a higher-privileged OEM process (e.g., a system app, platform-signed service, or native daemon). The goal is to reach an SELinux domain that has the necessary permissions to interact with the target kernel driver for Stage 2. The beauty here is its independence from chipset, kernel version, or phone model, as the same OEM service logic tends to ship across the OEM's lineup.

Stage 2: The Page Use-After-Free (UAF)

Once in a sufficiently privileged OEM domain, the second stage targets a page UAF in an OEM kernel driver. The choice of a page UAF is deliberate because its resulting primitive dramatically reduces reliance on typical Android kernel exploitation complexities.

A page UAF provides a persistent reference to a physical memory page after the kernel has freed and reallocated it. This stale reference – whether a CPU-side userspace VMA, a device-side IOMMU page-table entry, or a driver-held struct page pointer – allows an attacker to read and write kernel memory through a mapping they already control. By orchestrating the freed page's reuse as chosen kernel memory (e.g., a page-table page or a slab page holding critical structures), an attacker can achieve an arbitrary read/write primitive.

This primitive is highly stable: it operates at the page level, sidestepping slab-focused hardening like CONFIG_SLAB_BUCKETS or CONFIG_SLAB_FREELIST_HARDENED. It often negates the need for a KASLR leak because direct kernel pointer dereferencing isn't required. Being data-only, it bypasses control-flow protections such as CFI. Furthermore, the page allocator's behavior is remarkably consistent across kernel versions, ensuring broader applicability (e.g., 5.15 through 6.12).

Trade-offs and Practical Takeaways

The OEMpocalypse strategy is not without its limitations. Its primary trade-off is coverage: it's not cross-OEM. A Samsung chain won't work on a Xiaomi device, necessitating independent development for each target OEM. Even within a single OEM, component availability can vary; a vulnerable component on flagship Galaxy S and Z lines might be absent on an A-series phone. Thus, coverage is restricted to devices where the OEM ships the specific vulnerable component.

The second limitation is the maintenance burden. Each two-stage chain relies on at least two independent bugs. Across multiple OEMs, this amounts to a handful of vulnerabilities that must all remain unpatched simultaneously. A fix for any single bug requires finding a replacement, making it an ongoing effort.

Despite these costs, the strategy's attractiveness lies in its reliability and portability within an OEM's ecosystem. Where the vulnerable components exist, the same code often ships irrespective of the chipset or kernel version. This consistency allows for highly stable, page-level primitives that are less susceptible to the shifting sands of kernel hardening and device-specific configurations, offering a compelling path to rooting a targeted range of devices.

FAQ

Q: Why is a page Use-After-Free (UAF) preferred over other bug classes for the second stage?

A: A page UAF is chosen because it provides a physical page-level primitive that is highly stable and largely independent of common kernel hardening techniques. It operates at a coarser granularity than slab-level bugs, making it less sensitive to slab hardening, KASLR, and CFI. This directly translates to greater reliability and portability across different kernel versions and device configurations.

Q: How does the OEMpocalypse strategy address the challenge of KASLR?

A: The page UAF primitive typically allows reading and writing through a stale mapping that is already held by the attacker, rather than requiring the dereferencing of arbitrary kernel pointers. This significantly reduces or eliminates the need for an information leak to bypass KASLR, as the attack relies on controlling the content of a known physical page after its reallocation, not on discovering kernel memory addresses.

Q: What makes OEM-specific IPC endpoints a good target for sandbox escapes?

A: OEMs add a substantial amount of custom userspace code, including apps, services, and native daemons, which often expose numerous IPC endpoints. Unlike well-audited AOSP components, these OEM-specific handlers may contain logic flaws such as missing caller checks, improperly exported components, or unvalidated file paths. These vulnerabilities allow a less-privileged untrusted_app to interact with a more privileged OEM process, granting access to kernel drivers that would otherwise be protected by SELinux.