TL;DR: KernelSU-Next is an actively maintained community fork of KernelSU, the kernel-based root method for Android. Like the original, root lives in the Linux kernel — not user space — so it is harder for apps to detect. Its big advantage is broader device support, including many older and non-GKI kernels. As of June 2026 it sits at v3.2.0 and supports Android 16.
By the PrivacyPortal team. Last updated June 2026.
If you are researching kernel-based root on Android in 2026, KernelSU-Next is one of the names you will keep meeting. In plain terms it is a root manager — software that grants and controls superuser ("root") access on your own phone — built on the same idea as KernelSU: put root inside the kernel rather than bolting it onto the running system the way Magisk does. The practical payoff is that apps find it harder to spot, and that modules mount more cleanly. The practical cost is that it is tied to your kernel, so device support and setup vary. Below we cover what KernelSU-Next is, how it differs from the original, whether your phone qualifies, and exactly how to install it — with the real risks stated plainly.
What is KernelSU-Next?
KernelSU-Next (often written "KernelSU Next", or shortened to KSUN) is a community-maintained fork of KernelSU, the kernel-based root solution originally created by the developer tiann. "Kernel-based" is the key phrase: instead of patching the system from user space at boot, the superuser logic is compiled into — or loaded into — the Linux kernel itself.
In practice, three pieces work together:
- A patched kernel, or a loadable kernel module, that provides root.
- The ksud daemon, which handles su requests and runs your modules.
- A manager app, where you grant or deny root per app and toggle modules on and off.
Because the root component lives in the kernel, there is no separate system-level service sitting in the open for apps to fingerprint, and modules are mounted using OverlayFS — generally faster and tidier than Magisk's older "magic mount" method.
KernelSU was originally created by the developer known as tiann; KernelSU-Next is a community fork built on that codebase.
Kernel-space root (KernelSU-Next) versus user-space root (Magisk): a simple diagram of where the superuser logic actually lives.
KernelSU-Next vs KernelSU: what is actually different
The two share the same architecture, so day to day they feel similar. The headline of the KernelSU-Next vs KernelSU comparison is device support: KernelSU-Next deliberately reaches further down the device list, supporting many older and non-GKI kernels that upstream KernelSU does not officially cover. It also folds in extra manager conveniences, such as in-app SUSFS configuration, self-hiding options and a module WebUI.
As of mid-2026, upstream KernelSU is on the v3.2.x series and KernelSU-Next is at v3.2.0, with both supporting devices up to Android 16.
| Feature | KernelSU-Next | KernelSU (upstream) | Magisk |
|---|---|---|---|
| Root lives in | Kernel space | Kernel space | User space (patched boot) |
| Typical device support | GKI 2.0 plus many older/non-GKI kernels | Mainly GKI 2.0 (kernel 5.10+) | Almost any device with an unlocked bootloader |
| Easiest setup path | LKM (patch init_boot) or prebuilt KSUN kernel | LKM or prebuilt kernel | Patch and flash boot image |
| Module mounting | OverlayFS | OverlayFS | Magic mount / OverlayFS |
| Zygisk modules | Via ZygiskNext or ReZygisk | Via ZygiskNext or ReZygisk | Built in |
| Native hiding tech | SUSFS (kernel-level) | SUSFS (kernel-level) | Denylist (+ Shamiko) |
The short version: if your device is officially covered by upstream KernelSU, either will serve you well. KernelSU-Next earns its keep when your kernel is older or non-GKI, or when you want those extra manager features. You can read more at the KernelSU-Next project on GitHub and the original KernelSU documentation.
Why kernel-based root is harder to detect — and the honest limits
Many people move to KernelSU-Next from Magisk because, over time, some apps grew better at spotting Magisk's user-space footprint. A kernel-based design gives detection software less to latch onto, and the SUSFS patch set can hide root-related mounts and files from prying apps at the kernel level.
KernelSU-Next has no built-in Zygisk; to run Zygisk modules such as Play Integrity Fix you add a standalone provider like ZygiskNext or ReZygisk.
For Google's Play Integrity checks, the usual stack is a Zygisk provider (ZygiskNext or ReZygisk) plus a fingerprint-spoofing module like Play Integrity Fix, and sometimes Tricky Store for keystore attestation. Be realistic, though: detection is a constant arms race. We will never claim KernelSU-Next defeats any particular bank's checks — and some apps use hardware-backed attestation that no root setup reliably beats. SUSFS helps, but what passes this month may not pass next. If you depend on a finicky banking app, weigh that up before you start. For the wider picture, see our guide to passing Play Integrity with root.
Is your phone supported? GKI, non-GKI and LKM mode
KernelSU-Next is tied to your kernel, so the first job is to identify what you are running. Open Settings → About phone and find the kernel version. Kernels of 5.10, 5.15 or 6.1 usually mean your device has a GKI 2.0 kernel.
What "LKM mode" means
KernelSU-Next LKM (Loadable Kernel Module) mode loads root as a kernel module by patching the init_boot partition, instead of replacing your whole kernel. It is the most accessible route and the closest thing to the "patch an image and flash it" experience Magisk users know.
Use this quick decision framework:
- GKI 2.0 with init_boot (shipped on Android 13+): easiest path — patch init_boot in the manager and flash it. No custom kernel needed.
- GKI 2.0 on older Android: use LKM via the boot image, or flash a prebuilt KSUN kernel for your model.
- Non-GKI / older kernel: you need a kernel built with KernelSU-Next patches. Check your device's community for a prebuilt one — this is exactly where KernelSU-Next outshines upstream.
- No kernel source and no community kernel: KernelSU-Next may not be feasible; Magisk could be the better fit.
For background on the standardised kernel that makes the easy path possible, see Android's Generic Kernel Image (GKI) documentation. If you would rather not flash anything at all, the other route to a private device is to start with one that is already de-Googled — that is what we build with our de-Googled Android phones.
Checking the kernel version under Settings → About phone tells you whether you are on a GKI 2.0 kernel (5.10 or newer).
How to install KernelSU-Next (step-by-step)
Back up everything first. A safe KernelSU-Next install begins before you touch fastboot. Unlocking the bootloader erases all data on the phone, rooting can affect warranty and OTA updates, and a wrong step can bootloop or brick the device. The steps below modify your own device at your own risk; the LKM path is shown because it suits most modern GKI phones.
You will need: a full backup; a computer with Android platform-tools (adb and fastboot); a USB cable; your device's exact factory init_boot (or boot) image for your current build; and the KernelSU-Next manager — all listed in the Modules, apps & files to try section below.
- Back up your data, and copy your current init_boot/boot image off the phone so you can restore it if needed.
- Enable Developer options, then turn on USB debugging and OEM unlocking. Unlock the bootloader with fastboot flashing unlock (or your OEM's method). This wipes the device.
- Install the KernelSU-Next manager app from the files section below and open it. It will report "Not installed".
- Give the manager your factory init_boot image (or boot image on older devices). It patches the image for LKM mode and saves a patched file.
- Reboot to fastboot and flash the patched image to the matching partition, for example fastboot flash init_boot patched_init_boot.img. Do not flash to the wrong partition.
- Verify: reboot and open the manager. It should now show "Working" with a version and kernel string. Install a terminal app, run su, grant the request, and confirm you get a root shell.
- Optional — add Zygisk and hiding: install ZygiskNext or ReZygisk, then modules such as Play Integrity Fix, and configure SUSFS if your kernel supports it. Reboot after each change.
- Optional — hide the manager using its built-in option to randomise the app name and icon.
On a non-GKI device the idea is the same, but instead of patching init_boot you flash a prebuilt KernelSU-Next kernel for your exact model (steps 4–5). Always read your device community's notes first. New to bootloaders? Start with our guide to unlocking your bootloader safely.
The KernelSU-Next manager reporting a green "Working" status, with the kernel version string, after a successful LKM install.
Common pitfalls (and how to avoid them)
- Wrong partition: flashing a patched image to boot instead of init_boot (or vice versa) causes a bootloop. Confirm which partition your device uses.
- Mismatched image: always patch the init_boot/boot from your exact current build. An image from a different version will often bootloop.
- Magisk and KernelSU-Next together: never run both. Fully uninstall Magisk (use its "restore images" option) before switching.
- Manager newer than your kernel: if the latest manager will not activate, your kernel may be too old for it — use a build matched to your kernel, or a community kernel that includes current patches.
- OTA updates: a system update can replace your patched init_boot or kernel and break root or bootloop the phone. Re-patch after updates rather than taking OTAs blindly.
- Bad modules: a faulty module can bootloop you. Learn how to disable modules first — KernelSU-Next can boot with modules off, and you can remove them via recovery if needed.
- Expecting magic: SUSFS and spoofing modules are a moving target. Set them up, but accept that some apps may still refuse to run.
Frequently asked questions
Is KernelSU-Next safe to use?
It is widely used and stable, but rooting always carries risk: unlocking the bootloader wipes your data, a wrong flash can bootloop or brick the device, and root weakens some of Android's built-in protections. Back up first, only flash images that match your exact device and build, and make sure you know how to restore your factory images before you begin.
KernelSU-Next vs KernelSU — which should I pick?
If upstream KernelSU officially supports your device, either is a fine choice. Pick KernelSU-Next when your kernel is older or non-GKI, when no upstream support exists, or when you want its extra manager features such as in-app SUSFS configuration and self-hiding.
Does KernelSU-Next need a custom kernel?
Not always. On a GKI 2.0 device you can use LKM mode, which patches init_boot to load KernelSU-Next as a kernel module — no custom kernel required. On non-GKI or older devices you do need a kernel built with KernelSU-Next patches, which is where this fork tends to have wider coverage than upstream.
Will KernelSU-Next let my banking app or Play Integrity work?
Sometimes, with a Zygisk provider plus a fingerprint-spoofing module and good hiding — but there are no guarantees. Detection changes constantly, and some apps rely on hardware-backed attestation that no root method reliably passes. We will never promise KernelSU-Next beats a specific bank's checks.
Can I switch from Magisk to KernelSU-Next?
Yes. Fully uninstall Magisk first (use its "restore images" option so your boot/init_boot is clean), then set up KernelSU-Next via LKM or a custom kernel. Never leave both installed at once, as they will conflict.
Does rooting void my warranty or break updates?
Unlocking and rooting can void warranty depending on your manufacturer and country, and it changes how updates behave: a system update can overwrite your patched image, so you typically re-patch and re-flash after each update rather than installing OTAs normally.
