// HACKER NEWS — CYBERSECURITY
OEMpocalypse: Unprivileged Android app to root on Samsung, Xiaomi, others
Part 1 of a series that takes an unprivileged Android app to root on Samsung, Xiaomi, and Oppo/OnePlus/Realme devices, with a single strategy.
On Android, every third-party app runs in a sandboxed context called untrusted_app. If you ask five offensive security researchers how to go from this context to root, you will most likely get five different strategies, and each has its own trade-offs. Here, I describe the one I took and why, measured against three properties I use as a yardstick throughout:
The core idea is to only target code written by Original Equipment Manufacturers (OEMs) such as Samsung and Xiaomi. Specifically, I target a page Use-After-Free (UAF) in an OEM-specific kernel driver, using an OEM-specific sandbox escape to reach that driver where the OEM's SELinux policy requires one. In brief, a page UAF is a bug that leaves a live reference to a physical memory page after the kernel has freed it, and a sandbox escape is any bug that lets code cross from a lower-privilege process into a higher-privilege one. I then instantiated the strategy three times, once per major Android OEM, finding multiple vulnerabilities along the way and yielding chains that cover all Samsung flagship devices (at least the Galaxy S23 through S26 series and the recent Z series), a large share of Xiaomi mid-range to flagship devices, and recent Oppo, OnePlus, and Realme flagship devices.
Figure 1: The Samsung chain end to end on a bootloader-locked Galaxy S26 Ultra. Recordings for the other four tested devices are in The Three Chains at a Glance.
This first post explains the reasoning behind the strategy and compares it with two alternatives. The subsequent posts will provide technical details of these chains.
Before getting to OEM-specific code, it is worth stepping back and looking at what an unprivileged app can actually reach in the kernel, and what each kind of kernel bug offers for a weaponized exploit.
The list is short due to three layered mechanisms: standard Unix Discretionary Access Control (DAC) via Android's per-app UID model, SELinux as the Mandatory Access Control (MAC) layer on top, and system call filtering via seccomp. Every third-party app on Android runs under its own UID, in the untrusted_app SELinux domain (or one of its per-API-level variants such as untrusted_app_32), and behind a seccomp filter. DAC gates access via file ownership and mode bits, the SELinux policy restricts which device nodes, sockets, and filesystem paths the domain may access, and seccomp prevents the app from invoking a subset of system calls. The combined effect is that most of the kernel, and in particular most of the driver stack, is simply not reachable without first moving to a more privileged domain. In other words, DAC, SELinux, and seccomp together define the kernel attack surface you get to start from.
To make this concrete, let's take a current flagship line, e.g., the Samsung Galaxy S26 family, and enumerate the kernel attack surface from an untrusted_app process. On these devices, the list is roughly the following:
I should state that this enumeration is not meant to be exhaustive or authoritative. It is what I found on the devices in front of me, and the exact set may shift between models and Android releases.
Looking at that list, the entries loosely group by who wrote the code behind them: upstream Linux and Android Common Kernel code, chipset drivers, and OEM-specific code.