KernelSU-Next: root as a kernel feature rather than a patched binary
An advanced Kernel based root solution for Android
At a glance
- What is it?
- A kernel-based root solution for Android that hooks the su path in the kernel itself, with a split GPL licence, an LKM mode for GKI 2.0 devices and sixteen translated READMEs.
- Who is it for?
- KernelSU-Next is interesting less as a root manager than as an argument about where root belongs. Put the su path in the kernel and there is no patched boot image to keep matching to a device, which is the failure mode that makes many other approaches tedious.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Root implemented in the kernel, not bolted onto it
The feature list is three bullets long, and the first one carries the whole design: kernel-based su and root access management. Not a patched Magisk binary, not a modified system partition, a su implementation that lives in the kernel.
The practical difference shows up in the module system, which the second bullet describes as based on Magic Mount and OverlayFS. Magic Mount is the approach Magisk popularised for overlaying files into the running system without modifying the partition itself. The third bullet is App Profile, borrowed from KernelSU, which lets you grant or deny root per application.
The credits section is unusually candid about lineage. Kernel-Assisted Superuser is credited as concept inspiration, Magisk as the core root implementation, Genuine for APK v2 signature validation, Diamorphine for rootkit techniques, and the original KernelSU project as the base that made this possible, along with a specific Magic Mount port linked by commit. That is a fork with its history written down rather than hidden.
The project is large by community standards at 4290 stars and 1122 forks, with 16 open issues, and it was pushed to on 2026-09-23. Version 3.4.0 came out two days before that.
The compatibility table is the real documentation
KernelSU Next supports Android kernels from 4.4 up to 6.12, and the README breaks that range into three rows that behave differently.
| Kernel version | Support notes | | 5.10 and above, GKI 2.0 | Supports pre-built images and LKM or KMI | | 4.19 to 5.4, GKI 1.0 | Requires the KernelSU driver built-in | | Below 4.14, end of life | Requires the KernelSU driver, with 3.18 and above experimental and possibly needing backports |
Supported architectures are arm64-v8a, armeabi-v7a and x86_64.
Then there is the caution block, which is the single most important line in the README for anyone on a desktop-style Android image or an emulator: recent kernel versions have implemented a breaking change that causes KernelSU Next to fail and potentially trigger a kernel panic on x86_64. The README links to the website for details rather than explaining it inline.
A kernel panic is a hard failure, not a degraded experience, so this is worth resolving before you flash anything rather than after.
The module system borrows from Magisk on purpose
Magic Mount and OverlayFS are doing the work of letting you change system files without rewriting the system partition. For a root solution that is supposed to be a drop-in for how people already think about rooting an Android phone, using the mechanism Magisk popularised is a deliberate compatibility choice.
The v3.4.0 release notes show what a maintained fork looks like in practice, and the entries are mostly kernel-level correctness rather than user-visible features. Checking kernel_read results when verifying the APK signing block. Preventing stub_zygote from being unmarked. Validating the resetprop timeout value. Registering the TP handler minimum priority and allocation paths with a NULL check. Refactoring the allowlist in v3.3.0 and pruning redundant avtab nodes after deny rules. Adding an x64 LKM.
SELinux hiding and attribute and current detection arrive in v3.3.0, and the App Profile allowlist moves to ksu credentials in v3.2.0. These are the kinds of changes that matter when the thing you are patching is the kernel's own security machinery.
The release cadence is steady: v3.2.0 in April 2026, v3.3.0 in July, v3.4.0 in September.
A split licence, GPL-2.0 for the kernel part
The licence section splits the repository in two, which is unusual and worth understanding before you build on it.
The /kernel directory is GPL-2.0-only, and everything else is GPL-3.0-or-later. That is a sensible arrangement for a kernel-side project: the code that hooks the syscall path stays under the older GPL that kernel code is normally under, while the userspace tools and the manager can use the newer terms.
There is a small inconsistency to note. The badge in the README header says License GPL v2, which matches the kernel directory but not the rest of the repository, and the repository's own licence metadata says GPL-3.0. Both statements come from the project, and the licence section is the more specific of the two, so treat the kernel directory as GPL-2.0 and the remainder as GPL-3.0-or-later.
The build is driven by a justfile rather than a Makefile, with aliases for the two common tasks.
alias bk := build_ksud
alias bm := build_manager
build_ksud:
cross build --target aarch64-linux-android --release --manifest-path ./userspace/ksud/Cargo.toml
build_manager: build_ksud
cp userspace/ksud/target/aarch64-linux-android/release/ksud manager/app/src/main/jniLibs/arm64-v8a/libksud.so
cd manager && ./gradlew aDebugThat file also shows the layering: ksud is a Rust userspace binary cross-compiled for Android, and it is copied into the manager app as a native library before Gradle builds the APK. The repository tree confirms the split with kernel/, userspace/, manager/, uapi/, risk/, docs/ and website/ directories, and the default branch is dev rather than main.
Sixteen translations and a Crowdin project
The README exists in sixteen languages, and the contribution section points translations at Crowdin rather than at pull requests. The header line lists English, Simplified and Traditional Chinese, Turkish, Brazilian Portuguese, Korean, French, Indonesian, Russian, Ukrainian, Thai, Vietnamese, Italian, Polish, Bulgarian, Japanese and Spanish.
This matters more than the usual translation effort because the manager is where root permissions are granted. A user who cannot read the App Profile screen cannot tell what they are allowing.
Beyond language, the manager release is built on a nightly channel as well, with a badge pointing at a nightly.link workflow for build-manager-ci on the next branch. The tree contains an assets directory holding the logo used in that header and a justfile at the root.
Donations are accepted in USDT on BEP20 and ERC20, USDT on TRC20, and Litecoin, with the addresses printed in the README. It is a community-run project with commercial-adjacent donation rails and no company behind it, which is worth remembering when you weigh how much you depend on it.
Where the README stops and the website starts
The installation section is a single line: see the Installation guide on the project website. Everything about how you actually get this onto a device lives at kernelsu-next.github.io, not in the repository.
That is a real limitation for evaluation, but a defensible one. The compatibility matrix, the architecture list and the x86_64 caution are the parts that stay in the README because they are the facts you need before deciding whether to continue. The flashing procedure is per-device and per-kernel, so it belongs somewhere that can be updated without a release.
What the repository does give you is the source shape. The kernel directory holds the C code that hooks the syscall path, userspace holds ksud as a Rust crate plus the init hook, manager holds the Android application with the jniLibs directory where the native binary lands, and uapi is the interface shared between them. A risk directory and a docs directory sit alongside, and scripts and a website directory round it out.
The security contact is a separate SECURITY.md rather than the issue tracker, which is the correct convention for a project whose code runs before anything else on the device.
Editorial conclusion
KernelSU-Next is interesting less as a root manager than as an argument about where root belongs. Put the su path in the kernel and there is no patched boot image to keep matching to a device, which is the failure mode that makes many other approaches tedious. The cost is an explicit compatibility matrix and a real warning about x86_64 on recent kernels. Check the kernel version table against your device before anything else, read the installation guide on the project website rather than assuming the README covers it, and if you are on x86_64 treat the caution note as a blocker rather than a footnote.
Frequently asked questions
What are the key differences between KernelSU and KernelSU Next?
KernelSU-Next is a fork built on the original KernelSU, and the README credits that project as the base that made it possible while also crediting Magisk for the core root implementation and Diamorphine for rootkit techniques. It adds an x64 LKM, SELinux hiding, and continues the App Profile model for limiting root per application.
Is KernelSU better than Magisk?
The two take different approaches. KernelSU-Next implements su in the kernel itself, and its module system is built on Magisk's Magic Mount and OverlayFS, which the credits acknowledge. Whether that is better depends on your device: check the kernel version and architecture against the compatibility table, and note the README warning about kernel panics on x86_64 with recent kernels.
Can I use LSPosed with KernelSU Next?
The README does not address LSPosed or any specific module compatibility, so this cannot be answered from the project documentation. It states that the module system is based on Magic Mount and OverlayFS, which is a different mechanism from a root manager that patches the boot image, but module-by-module support is not covered.
How do I switch from Magisk to KernelSU Next?
The README does not document the migration. It defers all setup instructions to the Installation guide on the project website, and the practical starting point is checking your kernel version against the compatibility table, since 5.10 and above supports pre-built images and LKM while 4.19 to 5.4 requires the driver built in.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/kernelsu-next-kernelsu-next)Was this useful?