When our feed captured OEMpocalypse at 10:30 UTC on September 14, it had 68 points and 29 comments on Hacker News. That looked like a niche security post. The device list says otherwise. Researcher Lukas Maar demonstrated an ordinary Android app with no declared permissions reaching root on five stock, bootloader-locked phones: two Samsung models, a Xiaomi, an Oppo, and a OnePlus. The published research presents one method for building separate chains around each manufacturer's own code. It is a shared playbook with different vulnerabilities for each OEM.
Android's hardware fragmentation usually makes exploit development expensive. A technique that behaves on one kernel, memory layout, or chipset may fail on the next phone. Maar's governing choice was to target components attached to an OEM's software layer, such as One UI, HyperOS, or ColorOS. Those components can follow the brand across Qualcomm, Exynos, and MediaTek hardware. The OEMpocalypse strategy turns a source of Android variation into a way to shrink the porting matrix within one manufacturer's range.
The privilege path starts inside the OEM layer
Every third-party Android app begins with limited operating-system access. Android assigns each app a unique Linux user ID and runs it in its own process, while SELinux and system-call filtering add more boundaries. Google's Application Sandbox documentation says that this kernel-enforced design applies to native code as well as interpreted code. In the terminology used by Maar, an ordinary app starts in an untrusted_app SELinux domain. Root is far beyond that starting point.
Maar divides the available kernel attack surface by who wrote the reachable code. Generic Linux and Android Common Kernel bugs have the widest theoretical reach, yet an exploit has to survive differences in kernel versions, OEM patches, runtime settings, and device memory behavior. His test set stretched from Linux 5.15 to 6.12. The researcher's comparison says those differences often turn a portable bug into a collection of device-specific exploit adjustments.
Chipset drivers offer a different trade. Phones expose GPU, DSP, and NPU interfaces because apps need them for graphics or accelerated computation. A lifetime error in code that maps physical memory for one of those processors can give an attacker a strong memory primitive. Coverage then follows the silicon. The attack-surface analysis notes that Samsung alone ships flagship models with both Snapdragon and Exynos parts, so a chipset bug and a brand's product range do not line up neatly.
OEM code changes the coverage boundary. A Samsung service or driver can appear across Samsung phones with different processors because it belongs to the vendor software stack. Other manufacturers distribute their own components in the same way. Maar's stated target is one suitable driver bug per OEM, with an extra sandbox escape only when SELinux keeps an ordinary app away from that driver.
Two stages can cross the wall
The first stage, when required, lives in userspace. Android apps and privileged services communicate through Binder calls, intents, content providers, and local sockets. OEMs add their own system apps and daemons, which add more inter-process interfaces. A missing caller check, an exported component, or an unchecked file path can let an untrusted app make a privileged process act on its behalf. The stage-one description says the goal is to reach an OEM-owned process whose SELinux domain may open the target kernel driver.
Stage two targets a page use-after-free in that driver. In this bug class, software releases a physical memory page while some mapping or reference still points to it. If the kernel later reuses the page for sensitive data, the stale reference can read or alter the new contents. Maar says his chains arrange for reuse as a page-table page or as a slab page containing useful structures, then turn the surviving mapping into broader read and write access. That mechanism is detailed in the page UAF section.
This page-level route also explains the method's portability. Slab freelist protections act on a different layer. Control-flow integrity is less relevant when the exploit changes data instead of redirecting execution, and the stale mapping can remove the need to discover a randomized kernel address. In these chains, the same page-reclamation code ran unchanged across kernels 5.15 through 6.12, according to the researcher's account. That is a claim about the demonstrated chains, not a promise that every page UAF will behave the same way.
Five locked phones, three separate chains
Each demo printed the device state after exploitation. On the tested phones, the app began without declared permissions and reported the untrusted_app context. It then opened a root shell while verified boot remained green and the bootloader remained locked. The demo output included these lines:
User: uid=0(root) gid=0(root)
SELinux: Permissive
Verified boot: green
Bootloader lock: 1
VBMeta state: locked
Calif showed the Samsung chain on a Galaxy S26 and S26 Ultra, the Xiaomi chain on a Xiaomi 17, and the Oppo-family chain on an Oppo Find X9 Ultra and a OnePlus Ace 6 Ultra. All five were running the newest firmware available to the researcher in early August 2026. The table in the original report spans Android 16, Qualcomm and Exynos Samsung variants, and both Qualcomm and MediaTek devices in the Oppo family.
A Galaxy S23 appears in the test table for a different reason. Maar used a rooted S23 as the Samsung development phone, then ported the result to the locked S26 and S26 Ultra without equivalent kernel visibility. The report claims broader component coverage from at least the Galaxy S23 through S26 families and recent Z devices. It also claims most Xiaomi mid-range to flagship phones and recent Oppo, OnePlus, and Realme flagships. Those are coverage assessments by the researcher. The public demonstrations cover five named locked devices, and no Realme appears in the demo set.
The strategy gives up cross-brand universality. A Samsung chain does nothing on Xiaomi, and a two-stage chain fails when either bug is fixed. Maintaining coverage across three OEM groups requires several flaws to remain available at once. Maar calls that ongoing work in the trade-off section. In return, an exploit developer has less porting work inside the affected part of each OEM's range, even when the underlying chipset changes.
The policy wall still needs trustworthy code behind it
Android's SELinux documentation describes a default-deny system: an action is blocked unless policy explicitly allows it, and Android runs SELinux in enforcing mode. The chains depend on finding a userspace path into an allowed domain where the driver is not directly reachable. In that design, SELinux forces the attacker to supply another bug. It also means the driver's safety can depend on every vendor IPC handler that leads toward it.
Drivers that map kernel-owned pages into userspace or device address spaces must tear down every mapping before releasing a page. Maar writes that none of the kernel flaws in this series was subtle and argues that a focused lifetime review could have found them. His conclusion also warns against treating a driver as safe merely because a privileged SELinux domain stands in front of it. A flawed service can become the deputy that carries hostile input through the policy wall.
The report does not publish the individual vulnerabilities, CVE identifiers, exploit code, disclosure dates, or model-by-model patch status. It says later installments will explain the Samsung, Xiaomi, and Oppo-family chains. That limit matters. The demonstrations establish that the strategy worked on the listed early-August firmware, while the first installment does not establish that any specific phone remains exploitable now.
Parts two through four now have specific questions to answer: which components were affected, which firmware fixed each flaw, and where the claimed model coverage begins and ends. Part one proves the method on five locked phones. It does not provide a current exposure list for Samsung, Xiaomi, Oppo, OnePlus, or Realme owners, as the published scope and deferred technical details make clear.