A new open-source package called A12 GhostLock claims to root the Samsung Galaxy A12 (SM-A125F) with a single click from a Windows computer. The tool is built on GhostLock, a Linux kernel flaw tracked as CVE-2026-43499, and it is aimed at a phone where every mainstream root method is blocked by a locked bootloader. The project appeared on GitHub on 25 October 2026 with a first release and no stars yet, and its claims have not been independently verified yet.

What GhostLock is and why it matters here

GhostLock is described in the project documentation as a use-after-free flaw in the kernel's rtmutex and futex-PI code. According to the documentation, the flaw affects a very wide range of Linux kernels when a common configuration option is enabled, and it can be triggered by ordinary threading and futex system calls without special privileges. The flaw was reported in April 2026, fixed days later, backported in May, and publicly disclosed in July 2026, the project says. That timeline matters: this is a post-disclosure release built on a bug that is already fixed upstream, not a new vulnerability disclosure.

The Galaxy A12 angle is specific. The target is the SM-A125F running Android 12 on kernel 4.19.188, with a locked bootloader and SELinux enforcing. The documentation argues that KernelSU needs a kernel driver the phone cannot load, APatch and Magisk need a patched boot image the locked bootloader will not flash, and existing GhostLock ports need module loading this kernel does not allow. A12 GhostLock therefore brings its own userspace root stack instead of patching the kernel.

How the tool claims to work

The package is a Windows program that drives the phone over USB debugging. It reboots the phone, runs the exploit, and then checks three levels: SELinux switched to permissive, the phone still alive and sane on the same boot, and a parked process running as user id 0 with a forged capability set. Only if all three pass does it proceed to install its root layer and apps.

That root layer mimics KernelSU from userspace: it provides su, ksud, magisk and resetprop commands, a grant dialog that asks the user to allow or deny each app's root request, and hot module installation using overlay mounts, without rebooting. Three real apps were then driven through the dialog and verified by the commands they actually ran: Neo Backup, App Manager and Shizuku, with Shizuku's server running as root rather than at the usual ADB shell level.

Reliability, limits and risks

The release notes are unusually candid about reliability. Because the underlying technique can corrupt a kernel data structure, the phone sometimes panics and reboots during the attempt. The documentation reports 9 successful roots out of 12 first attempts on the test device, and success within three attempts in all 12 runs, with data left untouched after a panic. Root also disappears on reboot, since nothing is flashed and the bootloader stays locked.

The limits are strict. The tool works only on the SM-A125F on Android 12 with kernel 4.19.188, because kernel addresses are hard coded for that build. A different build will not match, and running it against a patched kernel fails cleanly, the documentation says. The capability set is partial, so some things do not work, including firewall apps based on iptables, and the bundled manager is described by its own author as a demo, not a hardened security boundary.

The risks are real too. Rooting can trip Samsung Knox, void warranties, and break banking and DRM apps. The release warns users not to run it on a device they do not own. Readers should also note the project has a single contributor and no independent review yet, so its verification claims should be treated as unverified until others reproduce them.

What this means for Galaxy A12 owners

For owners of this specific model, the release is notable because it offers a path where mainstream tools offer none, without unlocking the bootloader. For everyone else, it changes little: the underlying flaw is patched, the tool is single-device, and root vanishes at reboot. Its wider interest is as a case study in how far a userspace root stack can go on a locked-down phone, and how much of the rooting world now depends on emulating KernelSU rather than patching kernels.