Researcher demonstrates single unprivileged-app-to-root chain across Samsung, Xiaomi and Oppo phones

A security researcher has published the first part of a series, titled OEMpocalypse, claiming that a single exploitation strategy can take an ordinary third-party Android app from its sandbox to full root privileges on phones from three major vendors. According to the post on calif.io, which reached the front page of Hacker News, three instantiations of the same playbook cover at least Samsung's Galaxy S23 through S26 flagships and its recent Z-series devices, a large share of Xiaomi's mid-range and flagship phones, and recent Oppo, OnePlus and Realme flagships. The Samsung chain is demonstrated end to end on a bootloader-locked Galaxy S26 Ultra, with recordings offered for four other tested devices.

A playbook built on OEM code

Every third-party Android app runs in the sandboxed untrusted_app context, behind its own UID. The researcher judges candidate exploit strategies against three properties: reliability, meaning near-100 percent success whatever defenses a given vendor enables; portability, meaning minimal adjustment per kernel version, OEM, chipset or device; and universality, meaning one exploit covering as many phones as possible.

The chosen approach deliberately avoids generic Linux bugs. Instead it exploits a page use-after-free in an OEM-specific kernel driver — a bug that leaves a live reference to a physical memory page after the kernel has already freed it — and, where the vendor's SELinux policy gates that driver behind a privileged domain, reaches it through an OEM-specific sandbox escape. Every bug in the chain lives in code written by the device maker rather than in upstream Linux or chipset drivers.

Why not a generic kernel bug

From an app's vantage point, the kernel surface is narrowed by three layers: per-app Unix permissions, SELinux mandatory access control and seccomp system-call filtering. What remains reachable includes core syscalls and Binder, shared-memory and DMA-BUF heaps, the GPU driver — /dev/kgsl-3d0 on Snapdragon models such as the S26 Ultra, or a DRM render node on Exynos-based variants — plus DSP or NPU interfaces on some chipsets and a tail of OEM-specific device nodes.

Generic bugs in that surface are tempting because they cut across vendors, and the post singles out prior work such as IonStack, which drove one memory-management flaw to root across multiple OEMs' devices. But the researcher argues that the accessible core code has been audited for years, so what remains usually yields constrained slab-level primitives — a use-after-free of one object type, a bounded out-of-bounds write, a race that must be won — which then require heap grooming, cross-cache tricks and information leaks. Those techniques are sensitive to the target, and OEMs ship kernel versions from 5.15 to 6.12 with their own modifications layered on top, so a generic exploit must stay stable across several axes of variation simultaneously.

A page-level use-after-free reached from the right context, by contrast, can hand the attacker a stable primitive at the physical page level that, according to the post, is largely independent of kernel version, slab hardening, KASLR, CFI and the exact phone model. OEM-specific drivers also receive far less outside scrutiny than core Linux code, making them a comparatively softer target.

What is still to come

The published first instalment is a strategy essay: it lays out the reasoning and the trade-offs, while the technical details of the three chains are promised in follow-up posts. The author also cautions that the attack-surface survey reflects the devices at hand rather than an exhaustive or authoritative map, and that the reachable node set may shift between models and Android releases. The available text does not discuss vendor notification or patch status.

Why it matters

If the claims hold up as later posts land, the work undercuts a common assumption that Android's OEM fragmentation limits the blast radius of any single exploit. Here the vendor-specific code itself became the shared weakness, and one recipe was instantiated three times to cover much of the flagship market. The chain also starts from nothing more than an installed app and was demonstrated on a bootloader-locked flagship — the configuration most consumers actually run. And because page-level primitives sidestep the kernel hardening that vendors increasingly rely on, the finding points back to the root cause: out-of-tree OEM drivers and the SELinux policies that expose them.