GhostLock: a locked bootloader root exploit for OnePlus and OPPO phones

What GhostLock is for, and who should not touch it

Unlocking a bootloader wipes the phone and, on many recent models, is no longer offered at all. GhostLock is aimed at that gap: the repository describes a kernel exploit that gets temporary root and installs KernelSU on a device with a locked bootloader, without modifying the boot image. The audience is narrow. It is people who own a phone from the verified table, who want KernelSU modules or a root shell, and who accept that the privilege lasts until reboot.

It is not a general Android rooting tool. The README ships a not-feasible table listing phones that look like obvious candidates and still fail: OnePlus 12, OnePlus 13R, Ace 5, OPPO Find X9 Ultra, OPPO Pad 5, realme RMX5070, Motorola Edge 60 Fusion, iQOO Neo 10 CN, iQOO Z9 5G, iQOO 12, OPPO PKW110 and CPH2763. The reason is not an old kernel. It is the compiler's profile-guided optimization moving the freed waiter structure outside the region the exploit can control. A newer phone is not automatically safer or more exposed.

The futex PI use-after-free and the pselect6 stack overlay

CVE-2026-43499 is a use-after-free in the futex priority-inheritance code. The README states it affects Linux kernel 5.7 through 7.1 and is fixed in stable 6.1.175, 6.6.140 and 6.12.86, with most Android devices unpatched as of September 2026.

The mechanism is a stack overlay. The pselect6 syscall copies fd_set data onto the kernel stack. Combined with the futex PI waiter path, a freed stack frame can be reclaimed as an rt_mutex_waiter structure. The rb-tree rebalance during the PI chain walk then writes controlled values to addresses the attacker chose. GhostLock's contribution is the placement: with NFDS=320, core_sys_select allocates a 256-byte stack_fds buffer, and the exploit puts fake waiter fields (task, lock) into the fd_set input bitmaps, which are the user-controlled part of that buffer.

That is also the whole constraint. The README draws the buffer as words 0 to 14 user-controlled and 15 to 29 kernel-zeroed. For the 6.12 nested waiter, the maximum feasible waiter word is 3; for the 5.10 and 6.1 compact waiter, it is 7. Where the waiter actually lands depends on call-chain depth, which PGO and LTO decide.

Two root paths and how the exploit picks one

GhostLock selects between two paths at runtime based on device capabilities.

Path A, called UMH Root, is preferred on C ashmem devices and requires off_ashmem_misc_fops to be non-zero, meaning the ashmem driver has a static miscdevice in BSS. The README's flow is a PI write in mode 4 that redirects miscdevice fops to a fake fops table, then a configfs read/write pair giving a pipe-based physical read/write primitive with one-byte precision, then a single-byte write clearing SELinux enforcing, then a work_struct injected into system_unbound_wq that runs a root script and late-loads ksud. The README lists OnePlus 13, OPPO Pad 4 Pro and 5.10/6.1 C ashmem devices as supported. It is unavailable on 6.12 GKI devices because those use Rust ashmem, whose miscdevice is heap-allocated.

Path B is the fallback. Write 1 in mode 1 clears SELinux enforcing with an 8-byte write that the README says corrupts adjacent bytes. Write 2 in mode 2 points task->cred at init_cred, giving uid 0 and all capabilities. After both writes the exploit patches the SELinux policy binary's config field with |= 0xC0000000 for ANDROID_NETLINK_ROUTE and GETNEIGH and reloads it through /sys/fs/selinux/load to bring network connectivity back. Path B is cruder and leaves more to repair.

Building GhostLock with the NDK and running it

GhostLock is built from source with the Android NDK. The Makefile reads ANDROID_NDK_HOME or ANDROID_NDK_ROOT, defaults API to 35, and targets aarch64-linux-android. There is no package to install and no release artifact published; the repository root holds a Makefile, src/, tools/ and assets/.

Set the NDK path and build. The output binary is named ghostlock.

NDK_ROOT ?= $(or $(ANDROID_NDK_HOME),$(ANDROID_NDK_ROOT))
make API=35

The README's example invocation is a binary placed at /data/local/tmp/a/e, run with no arguments for auto-detection:

/data/local/tmp/a/e

The runtime detects the kernel version and consults a multi-device offset table. If the physical load address is wrong the README says the run fails silently, so verify it first on a rooted unit:

su -c 'grep -i "Kernel code" /proc/iomem'

A line starting c7810000 corresponds to kernel_phys_load 0xc7800000, the value the README lists for SM8850 devices (OnePlus 15, Xiaomi 17). SM8845, SM8750 and SM8650 use 0xa8000000. You can override at runtime: KPHYS=0xc7800000 /data/local/tmp/a/e. The README also names PSELECT_SHIFT as a tunable, without documenting its values.

Why the same chipset roots on one phone and not another

The most useful part of the README is the feasibility table, because it contradicts the intuition that kernel version decides everything. It does not. The README states plainly that where the freed rt_mutex_waiter lands is determined by compiler PGO/LTO profiles, not the kernel version.

Compare two entries. OnePlus 15 with build PLK110 on 6.12.58 is listed as verified working with SHIFT 0. OnePlus 15 with build PLK110 on 6.12.69 is listed as not feasible because PGO inlines do_futex and the waiter ends up at word 20. Same model, same SoC, different firmware. The android16-5 and android16-6 call chains (sys_futex to do_futex to fwrpi) give waiter word 2 and work; the OPLUS 6.12.69 chain (sys_futex to fwrpi) does not.

The 6.1 situation is messier. OPLUS 6.1 kernels are consistently infeasible because of PGO inlining, but the README notes that some non-OPLUS 6.1 kernels, specifically vivo's, keep the standard call chain and are feasible, citing vivo T4 and X Fold3 Pro with waiter word 3. The README's own instruction is that feasibility must be checked per device. Treat the verified table as a whitelist, not as a starting point for extrapolation.

Bootstrap mode, auto-boot and what happens after reboot

Two operational details matter more than the exploit chain for day-to-day use.

First, bootstrap mode. The README describes an app that runs under seccomp, performs Write 1, and then starts a mini-adb TCP server so the rest of the exploit can run through adb shell on the phone itself. That is the standalone path, for when there is no host machine.

Second, persistence. GhostLock itself does not survive a reboot. The README points to a separate project, the GhostLock Anchor app, for the boot-time launcher. That is a real dependency: if you want root after a restart, you are relying on software outside this repository, and the README does not document what Anchor does beyond being the boot-time launcher.

On the KernelSU side, the exploit late-loads ksud. The README notes KernelSU running in LKM, Jailbreak mode in its screenshot caption. Nothing in the README describes rollback, uninstallation, or how to return the device to a clean state after a run.

Alternatives, and when unlocking the bootloader is still the better answer

The conventional route to KernelSU is an unlocked bootloader plus a patched or custom boot image. The difference is structural: unlocking changes the device state once and then everything is a normal fastboot flash, whereas GhostLock leaves the bootloader locked and re-derives root from a memory-corruption bug on every boot. The trade is persistence and predictability against not wiping the phone and not tripping the unlock flag.

If your device is already unlockable, the bootloader route is the one with a documented recovery path. GhostLock's README does not document rollback, and its Path B deliberately corrupts bytes adjacent to the SELinux enforcing flag before repairing the policy binary. If your model appears in the not-feasible table, no amount of configuration will help, and unlocking is the only path the README supports.

Magisk-style systemless rooting is a third option, but it also assumes an unlocked bootloader or a patched image. GhostLock's only claim over these is the locked bootloader constraint.

Editorial conclusion

GhostLock is for owners of the exact devices in the verified table who want KernelSU without touching the bootloader, and who can read a kernel call chain or at least a build log before trusting a run. It is not for anyone whose phone appears only in the not-feasible table, and not for anyone who needs persistent root, because the README describes the root as temporary and a reboot clears it. Check three things first: whether your model and build appear in the verified table, whether the bootloader reports the kernel_phys_load value the table expects for your SoC, and whether your device uses C ashmem or Rust ashmem, since that decides between the preferred UMH path and the fallback PI write.

Frequently asked questions

Official sources

1. Issues
2. JoinChang/ghostlock-oneplus on GitHub
3. README