KernelSU: Rooting Android Through the Kernel Instead of the Boot Image
A Kernel based root solution for Android. Compatibility state KernelSU officially supports Android GKI 2.0 devices (kernel 5.10+).
At a glance
- What is it?
- KernelSU moves root management into the kernel itself for GKI 2.0 devices. It trades Magisk-style boot image patching for a kernel module, with real compatibility limits and a recent x86_64 warning.
- Who is it for?
- Adopt KernelSU if you run a GKI 2.0 device (kernel 5.10+) and want root management that lives in the kernel, not the boot image. Skip it if your device uses an older kernel below 4.14, if you need arm or x86 (32-bit) support, or if you cannot risk a kernel panic on x86_64.
- 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 1 day 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 September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What KernelSU Actually Changes
KernelSU is a root solution that puts the su daemon and root access management inside the Android kernel itself. The README describes it as a kernel-based root solution, and the credits trace the idea to Kernel-Assisted Superuser. For a user, the visible difference from Magisk is that KernelSU does not patch the boot image. Instead, the kernel is built with KernelSU integrated, or a GKI kernel is replaced or patched. This means root access is controlled at the kernel level, not through a userspace daemon that can be detected or bypassed. The project targets Android GKI 2.0 devices with kernel 5.10 and newer. GKI, the Generic Kernel Image, is Google's effort to standardize the kernel across devices, which makes a single kernel module viable. KernelSU is for users who want root on modern devices without modifying the boot image, and for developers who build custom kernels.
The Mechanism: Kernel-Level su and Metamodules
The core mechanism is a kernel module that provides su and root management. The README lists three features: kernel-based su and root access management, a module system based on metamodules, and App Profile. Metamodules are described as pluggable infrastructure for systemless modifications. The term systemless is not defined in the README, but in the Android root context it usually means changes do not touch the system partition. App Profile is described as a way to lock up the root power in a cage, which suggests per-app restrictions on what root can do. The architecture is not detailed in the README, but the kernel directory is separate from the rest, and the dual license hints at that split. The kernel parts are GPL-2.0-only, while everything else is GPL-3.0-or-later. That split matters if you plan to distribute a kernel built with KernelSU: the kernel code stays under GPL-2.0, which is the typical license for Linux kernel code.
Getting It Running: Installation and Build Paths
The README points to the official website for installation and build instructions. It does not list exact commands, but it gives the two paths: for GKI 2.0 devices you can use a prebuilt kernel or patch your existing one, and for older kernels (4.14+) you must build the kernel manually. The compatibility state says KernelSU officially supports GKI 2.0 devices with kernel 5.10 and newer. Older kernels 4.14 and up are supported but require manual building. That means if you have a device with a kernel between 4.14 and 5.10, you cannot just flash a kernel; you need a build environment. The README also says WSA, ChromeOS, and container-based Android are supported, which broadens the scope beyond phones. Architectures are limited to arm64-v8a and x86_64. There is no arm (32-bit) or x86 (32-bit) support. To get started, you would visit kernelsu.org, download the appropriate kernel for your device, and flash it via fastboot or a custom recovery, but the exact steps are on the website, not in the README.
A Real Limitation: The x86_64 Panic Warning
The README carries a clear caution: recent kernel versions have implemented a breaking change that causes KernelSU to fail and potentially trigger a kernel panic on x86_64. This is a serious failure mode. A kernel panic means the device crashes and may not boot. The warning directs users to the website for more info, but the README does not say which kernel versions are affected or what the breaking change is. This is a genuine reason not to adopt KernelSU on x86_64 devices, which includes many ChromeOS devices and WSA instances, until you verify the specific kernel version. For arm64 devices, the warning does not apply, but the absence of a similar warning for arm64 does not mean there are no issues. The README is thin on failure modes beyond this one. That is a gap. You should check the website and the issue tracker before deploying on any device.
Wrong Tool Cases and an Alternative: Magisk
KernelSU is the wrong tool if your device has a kernel older than 4.14, because it is not supported at all. It is also wrong if you need 32-bit architecture support, which is absent. If you want to avoid building a kernel manually, and your device is not GKI 2.0, KernelSU becomes a build project rather than an install. The obvious alternative is Magisk, which the README credits as a powerful root tool. Magisk works by patching the boot image, not the kernel. That is a different approach: Magisk modifies the ramdisk and adds a magiskd daemon in userspace, while KernelSU embeds root in the kernel. The practical difference is that Magisk supports a much wider range of devices, including older kernels, without manual kernel builds. Magisk also has a larger module ecosystem. KernelSU's metamodule system is newer and less proven. If you need broad device support and a mature module ecosystem, Magisk is the safer choice. If you want kernel-level control and you have a GKI 2.0 device, KernelSU is the specific tool.
Maintenance, Licensing, and Translation Notes
The project is actively maintained, with releases in June and August 2026 (v3.2.5 and v3.3.0). The last push date matches the latest release, so development is ongoing. The license is dual: kernel files are GPL-2.0-only, and the rest is GPL-3.0-or-later. This matters if you build a kernel with KernelSU and distribute it. GPL-2.0 requires you to provide source code for the kernel, which is standard for Linux kernels. GPL-3.0 for the userspace parts has additional requirements, such as patent grants and anti-tivoization clauses. This is not legal advice, but you should be aware that combining KernelSU with proprietary kernel modules could be problematic. The translation process changed: the project no longer accepts Weblate contributions and now uses LLMs for translations. That is an unusual maintenance choice. It means translations are not human-reviewed, which could affect quality. If you rely on non-English docs, verify them against the English version. The README also states that modifications to existing English and Chinese translations are not accepted, so community corrections to those are closed.
Security and Vulnerability Reporting
The README mentions a SECURITY.md file for reporting vulnerabilities, but it does not summarize the policy. That is a thin spot. For a root solution, security is the central concern. A kernel-based root has a larger attack surface than a userspace daemon, because a vulnerability in the kernel module could give an attacker kernel-level code execution. The existence of a security policy is good, but the README does not state whether there is a bug bounty, a responsible disclosure timeline, or a list of known vulnerabilities. You should read SECURITY.md before adopting KernelSU. The project also credits Diamorphine, a rootkit, for some rootkit skills. That is a signal that the code includes techniques for hiding or evading detection, which is normal for root solutions but also a double-edged sword. It makes KernelSU more stealthy, but it also means the code is deliberately designed to bypass security mechanisms. That is a trade-off you should accept consciously.
Editorial conclusion
Adopt KernelSU if you run a GKI 2.0 device (kernel 5.10+) and want root management that lives in the kernel, not the boot image. Skip it if your device uses an older kernel below 4.14, if you need arm or x86 (32-bit) support, or if you cannot risk a kernel panic on x86_64. Before installing, verify your exact kernel version against the compatibility table on the official website, check the x86_64 breaking change notice, and confirm that the metamodule and App Profile features cover the modules you currently use with Magisk. The project is actively maintained (v3.3.0 released August 2026), but the x86_64 panic risk and manual kernel building for older devices are concrete reasons to test on a spare device first.
Community notes