DirtyFrag sharpens an Android root chain for locked Samsung and OnePlus phones

The public Android rooting project DirtyFrag has released version 1.16, a substantial reliability update to a chain built around CVE-2026-43284. The project demonstrates how a Linux kernel networking flaw can be carried from an ordinary Android application context to temporary root access on selected phones whose bootloaders remain locked. The October 15 release is notable less for unveiling a new vulnerability than for documenting the difficult engineering needed to make a known primitive survive vendor hardening on real Samsung, Oppo and OnePlus devices.

This is not a remote zero-click compromise. A user or attacker with local access must install and run the application on a compatible, vulnerable device, and the result depends on its kernel, firmware and security configuration. DirtyFrag is therefore best understood as a public post-access root chain and a security research artifact. It is still important: bootloader lock is often treated as a strong boundary, and the project shows how a kernel write primitive can route around that boundary without permanently modifying the boot chain.

From encrypted packets to a kernel write primitive

At the bottom of the chain is CVE-2026-43284, a flaw in the Linux kernel's IPsec ESP handling. In simplified terms, pages attached to certain UDP packets could remain shared while the kernel decrypted packet data in place. That mismatch created a page-cache write primitive: carefully controlled encrypted data could alter bytes in a file-backed page even though the process did not possess normal write permission for that file. The upstream kernel fix makes the networking path copy shared data before decryption, closing the ownership error rather than attempting to block one exploit payload.

DFRoot, the upstream Android implementation, connects that primitive to several Android-specific trust boundaries. Conceptually, the chain first uses an accessible IPsec interface to obtain controlled writes, then borrows a more privileged crash-handling context to reach vendor-labelled files. A later stage modifies code that will be mapped by a privileged system process, allowing that process to load a purpose-built kernel module. The module establishes the root environment expected by a compatible superuser manager. Each stage solves a different problem: writing to protected storage, crossing SELinux domains and finally executing in the kernel.

Why version 1.16 matters

DirtyFrag is a hardened fork of DFRoot, and version 1.16 incorporates upstream DFRoot 4.5 while changing how the chain handles vendor defenses. Earlier builds tried to unload several Oppo and OnePlus security modules. On at least one reported OnePlus configuration, that action triggered an anti-tamper path and produced a black screen on every run. The new build leaves those modules loaded and patches the relevant checks in place. It applies a similar approach to Samsung DEFEX handlers, reducing the chance that a defensive subsystem reacts catastrophically during the chain.

The update also changes how the kernel module launches its user-space helper, avoids waiting for the helper process to finish, and cleans up the temporary module earlier. Those details address failures observed in the preceding v1.15 release, including a bootstrap that stopped at verification on non-Oppo kernels. The release notes cite testing on Samsung devices and describe fixes for a Galaxy A34 module-loading failure. A revised payload loader now searches executable alignment padding for a large enough code cave instead of assuming that sufficient slack exists at the end of a segment, which should make the chain less dependent on one library layout.

A full chain, but not a universal one

The project supports a range of Android Generic Kernel Image families, but a supported family is not proof that every phone using it is exploitable. OEMs backport patches, change kernel configurations and add device-specific controls. Some builds may already contain the fix or an accidental mitigation; others may fail because the expected library layout, symbol set or vendor security behavior is different. The latest release itself is evidence of that variability: moving from a working primitive to stable root required separate handling for pointer authentication, executable preambles, vendor modules and individual firmware behavior.

Root obtained this way is described as ephemeral: rebooting removes the loaded module and the immediate superuser environment. That limits persistence by design, but it should not be mistaken for automatic remediation after a hostile run. Root access can expose credentials, alter application data or install a separate persistence mechanism before the reboot. Conversely, the existence of a downloadable APK does not mean an internet attacker can silently compromise a phone; installation and local execution remain essential preconditions in the published workflow.

For Android security teams, DirtyFrag is a useful case study in why a kernel patch and a mobile exploit chain are not the same deliverable. The vulnerability supplies a narrow write capability; the chain turns it into something operational by navigating Android services, SELinux labels, vendor hardening and kernel-module loading. Version 1.16 makes that bridge more reliable, while its long list of device-specific fixes also sets the proper boundary around the claim: this is a serious and technically complete local chain, not evidence of a universal remote Android takeover.

Sources: DirtyFrag v1.16 release notes; Upstream DFRoot v4.5 release; DirtyFrag v1.15 release notes.

Corrections: Report an error at corrections@wireshaman.com.