GhostLock: a one-tap kernel exploit app for specific Android builds

What GhostLock actually is, and who the kernel table is for

GhostLock is a C application with an Android front end, published by YuKongA under Apache-2.0, that carries an exploit for CVE-2026-43499. The README opens with a device table rather than a feature list, and that ordering tells you what the project considers its main constraint. Each row pairs a kernel release string, for example `6.6.118-android15-8-g93e223c276e7-abogki500782043-4k`, with the phones that ship it: OPPO Find X8 Ultra, OnePlus 13, ACE 5 Pro. The table spans 6.1, 6.6 and 6.12 Android trees and covers devices from Xiaomi, POCO, Redmi, OPPO, OnePlus, vivo, Honor, Motorola, Asus, Infinix, Nothing, nubia and Red Magic.

The audience follows from that table. This is not a tool for a general Android user who wants root. It is for someone who already has a rooted device with a kernel-level root manager, has read about CVE-2026-43499, and wants a packaged way to exercise the route on hardware they own. The README's own framing is minimal: open the app, tap Run. Everything else in the repository exists to make that tap land on the right kernel.

Exact uname -r matching, and what happens when it fails

The README states that kernels are matched by exact `uname -r`, that unsupported builds are rejected, and that the app shows the status at the top. There is no fuzzy match on kernel version, no fallback to a nearby build, and no attempt to guess offsets. A device running `6.6.89-android15-8-g0889fe95bb10-ab14402178-4k` will not be treated as compatible with `6.6.89-android15-8-g8e4be6b47e40-ab14134548-4k`, even though the version numbers agree.

That is a defensible choice. Kernel exploitation depends on structure layouts and symbol offsets that change with every build, so a near-miss match is more dangerous than a refusal. The cost is that the supported list is a snapshot. New firmware, a different regional build, or a vendor respin moves you off the list until someone adds offsets.

Offsets live in `src/kernels/<uname-release>/offsets.h`. The README says new builds are added with the extractor's `--register` flag, which puts offset generation in the hands of whoever has the kernel image. The README does not document what the extractor does when a symbol is missing, nor whether a partially registered build is rejected before or after the exploit runs. That is the first thing I would probe before trusting the app on a build I registered myself.

Two routes: the tree-waiter race and the compact-waiter path

The exploit does not use one technique. The README describes the route as racing two cores, with the branch chosen by kernel family. On the 6.6 and 6.12 tree-waiter kernels, the main thread hammers `select` while a consumer thread perturbs the waiter's priority. On the 6.1 compact-waiter kernels, the main thread drives `getsockopt(TCP_ZEROCOPY_RECEIVE)` through what the README calls a punched-hole page path.

So the same app ships two different primitives behind one Run button, and the kernel release string selects which one executes. That explains the shape of the device table: the 6.1 rows and the 6.6/6.12 rows are not just different offsets, they are different code paths. It also means a failure on a 6.1 device tells you nothing about whether the 6.6 path works, and vice versa.

The README excerpt ends mid-sentence in the description of the compact-waiter path, so the full sequence for the 6.1 branch is not documented in what I can see. Anyone evaluating the 6.1 route should read `src/core/main.c` and `src/core/fops.c` rather than rely on the prose.

Installing and running it for the first time

The repository ships a Makefile that builds the native binary with the Android NDK and a Gradle project that wraps it in an APK. The Makefile auto-detects the NDK on Windows from `%LOCALAPPDATA%/Android/Sdk/ndk/*`, `%ANDROID_HOME%/ndk/*` or `D:/AndroidSDK/ndk/*`, and on other platforms from `ANDROID_NDK_HOME` or `ANDROID_NDK_ROOT`. The default API level is 35 and the target is aarch64.

To build the native binary:

make

You should see the NDK compiler path echoed, then the target config, and finally a `ghostlock` binary in the repository root. The `product` target prints the same confirmation plus the Gradle command for the APK:

make product

The APK itself is built through the Gradle wrapper:

./gradlew :app:assembleDebug

The README's Quick Start says to open GhostLock and tap Run. Before that tap, check the status line at the top of the app: the README says unsupported builds are rejected and the status is shown there. Module loading depends on a root manager that provides `ksud`: KernelSU (`me.weishu.kernelsu`), ReSukiSU (`com.resukisu.resukisu`) or KowSU (`com.kowx712.supermanager`). The README is explicit that without one of these, the W1/W2 path still grants uid 0 but no module is loaded. So a successful Run on a device without those packages is a partial result, not a failure.

The ksud dependency and the module-loading gap

The most understated line in the README is the one about `ksud`. It splits the outcome of a Run into two independent things: whether the exploit grants uid 0, and whether a module gets loaded. The second depends entirely on an external root manager being installed and exposing `ksud` under one of three package names.

That split matters for interpretation. If you run GhostLock on a device with no supported root manager and the status says the route succeeded, you have uid 0 in that process and nothing persisted. Users who expect a one-tap root that survives a reboot will be disappointed, and the README does not describe any persistence mechanism of its own. The app is an execution surface for the exploit, not a root management layer.

The same paragraph also implies the app will run on a device where no module can be loaded without warning you beyond the README text. Whether the UI surfaces that distinction is not stated. Verify it on your own hardware before assuming the status line means what you think.

Where GhostLock is the wrong tool

If your kernel is not in the table, GhostLock cannot help you today. The README does not describe a generic exploit, a version-range match, or a scanning mode that tries multiple offset sets. Rejection is the designed behaviour.

If you want root for daily use rather than to exercise a specific CVE, this is the wrong layer. GhostLock depends on KernelSU, ReSukiSU or KowSU being present for module loading, so those projects already provide the persistent root you would be looking for. Using GhostLock instead of installing one of them inverts the dependency.

If you are evaluating patch status or doing security research at scale, a single-device app with a hardcoded kernel list is a poor fit. The interesting artifact for that work is the offset extractor and the `src/kernels/` tree, not the APK.

And if you cannot verify the provenance of a prebuilt APK, the source build path is the one to use. The Makefile and Gradle wrapper are both in the repository, so there is no reason to trust a binary you did not compile.

How it compares to a general root solution

KernelSU, ReSukiSU and KowSU solve a different problem. They install a kernel-side root interface, manage module loading, and persist across reboots. GhostLock is a single exploit path for one CVE, and it borrows `ksud` from those projects rather than replacing them.

The practical difference shows up in what each one knows about your device. A root manager is built to be kernel-version tolerant and to keep working across updates. GhostLock is built to be exact and to refuse anything else. If you are already running one of the three root managers, GhostLock adds an exploit route on top of an existing root, which is a narrow addition. If you are not running one, GhostLock gives you uid 0 in a process and no module loading, which is a much smaller result than the word root suggests.

Licence, build cost and what to check next

The repository is Apache-2.0, which permits commercial and private use with the usual notice and patent terms. That is a permissive licence, and it is worth noting that a kernel exploit published under a permissive licence can be redistributed freely, including in forms the original author does not control. This is a description of the licence text, not legal advice; if you plan to ship anything derived from it, read the LICENSE file and get your own counsel.

Upgrade cost is dominated by the kernel table. Every new firmware build that changes `uname -r` needs a new `src/kernels/<uname-release>/offsets.h`, generated with the extractor's `--register` flag. The Makefile already treats headers as rebuild triggers, with a comment noting that a freshly registered `offsets.h` should force a rebuild. So the maintenance loop is: new build appears, someone extracts offsets, the table grows. If nobody does that for your device, the app rejects it.

The last push to the repository was on 2026-09-17, the same day as the GhostLock pre-release. That is recent activity, and the release is marked pre-release, so treat the current state as a moving target rather than a settled tool.

Editorial conclusion

GhostLock is for people who already run KernelSU, ReSukiSU or KowSU on one of the listed kernel builds and want to see whether the CVE-2026-43499 route grants uid 0 on their own device, with the app's status line as the only verdict. It is not for anyone on an unlisted build, for anyone expecting a general-purpose rooting tool, or for anyone who cannot read a kernel release string and compare it to a table. Before you tap Run, check `uname -r` against the README table, confirm your root manager package is one of the three named, and read src/kernels/<uname-release>/offsets.h to see whether offsets for your build exist or would have to be added with the extractor's --register flag.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. YuKongA/ghostlock-app on GitHub