# OnePlus_KernelSU_SUSFS: a rooted OnePlus kernel with root hiding > WildKernels builds Android kernels for OnePlus, Oppo and Realme that combine KernelSU with SUSFS root hiding, a Baseband Guard patch set and a stack of networking tweaks. It suits owners who can flash a custom kernel and read the compatibility list before they do. **WildKernels/OnePlus_KernelSU_SUSFS** — OnePlus Kernels with KernelSU & SUSFS - Repository: https://github.com/WildKernels/OnePlus_KernelSU_SUSFS - Stars: 733 · Forks: 854 - Language: Unknown - License: not declared - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/wildkernels-oneplus-kernelsu-susfs ## A OnePlus kernel whose selling point is in-kernel root The project is described simply as OnePlus kernels with KernelSU and SUSFS, and its repository topics spell out the scope: android-kernel, gki, kernel-build-script, kernel-builder, ogki, oki, oneplus, oneplus-kernel, oppo and realme. That is a kernel image for a specific device family, not a root manager app. The root itself comes from KernelSU, and the readme describes the mechanism plainly: it works in kernel mode and grants root permission to userspace applications directly in kernel space. SUSFS is layered on top as an addon root hiding patch set with its own userspace module, so the practical difference from an ordinary rooted phone is that applications inspecting the system have less to find. A second layer, the WildKSU Manager, is a root manager from the same team with additional customisations, which is what you would use to grant and revoke permissions once the kernel is running. ## The feature list is a bundle of patches from several upstreams Read the feature list closely and it decomposes into work contributed by different projects. Security relevant entries include BBG, an LSM-based Baseband Guard that protects critical device partitions and can whitelist abl and efisp on devices with that efisp exploit. Networking entries include BBRv1 and BBRv3 for TCP congestion control, CAKE and PIE qdisc support, TTL target support for packet manipulation, and IP set plus IPv6 NAT. Scheduler work is listed as HMBIRD SCX, but it is scoped to SM8750 and MT6991 chips, so on other hardware that particular entry buys you nothing. The rest is platform plumbing: LTO enabled, general memory, I/O and CPU scheduler tunings, TMPFS XATTR and POSIX ACL support for meta modules and Mountify, Droidspaces for running portable Linux containers, NTSync primitives compatible with the Windows NT kernel API, and an experimental fix that prevents path traversal through non-printable Unicode codepoints. The result is a broad bundle rather than one coherent theme, and every separate subsystem is its own surface to trust. ## Device support is checked in compatibility.md, never assumed The readme is explicit that you should verify device compatibility before flashing and points at compatibility.md in the main branch for that list. That file is the gate for the whole project, since a kernel built for one device family will not simply work on another. The repository layout backs this up: the top level contains a .github directory, .gitignore, README.md, compatibility.md, a configs directory and a manifests directory, which is the shape of a build definition and a tracking surface rather than a patched kernel tree you would read to learn behaviour. Two consequences follow. First, the project is not a place to look for kernel source changes, because the interesting decisions live in configuration and manifests. Second, if your model is missing from the compatibility file, no amount of reading the feature list changes that, and the correct move is to stop rather than to try a neighbouring device's build. ## The installation steps are not in the readme There is no command to copy here, and the project does not pretend otherwise. The Installation Instructions section sends GKI users to the official KernelSU Installation Guide and adds that installation instructions can also be found in the release notes. Additional resources listed are a separate Kernel Patches repository and KernelFlasher, a flashing tool maintained by the same author, alongside the WildKSU Manager for managing root once the kernel is live. So the practical sequence for a new user is: confirm the device appears in compatibility.md, pull the matching release asset, follow the official guide or the release notes for the flashing steps, then install the manager and the SUSFS module. Every one of those steps is described somewhere other than the readme, which is a fair trade for a project whose flashing documentation has to stay in step with the KernelSU upstream, but it does mean you should not treat this page as a complete procedure. ## An upstream tracker that runs every two hours Alongside the readme there is a tracking status page hosted in this repository at status-page/README.md, described as a live dashboard for OnePlus repositories tracking and changes, with an update frequency of every two hours and marked automated. That cadence is the most interesting engineering decision in the project. OnePlus ships its own kernel source upstream, and those upstream commits keep arriving whether or not anyone flashes a custom kernel, so a tracker answers the question every custom kernel maintainer has to answer manually: has upstream moved since my build. The tension is obvious. The tracker refreshes every two hours, while the published builds moved on a scale of weeks, with releases v2.2.0-r2 on 2026-06-30, v2.2.0-r3 on 2026-07-21 and v2.2.0-r4 on 2026-08-12. A device running an August build is therefore sitting on code that upstream has already moved past, and the tracker will show you that gap without filling it. ## Flashing risk, warranty and the honest limit of the disclaimer The readme states that flashing this kernel will not void the warranty but that there is always a risk of bricking your device, tells you to back up your data and understand the risks first, and explicitly places responsibility on the person flashing. The author also asks that you research the features added in the kernel before flashing, which is a reasonable request given the list above: a Unicode traversal fix and an LSM baseband guard are not cosmetic. Where the disclaimer stops being reassurance is scope. It covers a device that fails to boot, but it does not cover the harder cases, such as a partition write that succeeds and leaves a device that boots into a broken state, or a Baseband Guard configuration that interacts badly with your network. If your recovery path depends on the same phone you are flashing, that is a real limit on how much the warranty note helps. ## Device specific build or the generic GKI one The same team publishes several kernels, and the available kernels table lists GKI, Sultan, OnePlus/Oppo/Realme and Samsung, all marked active. The GKI repository is the generic option: it produces a kernel image for the GKI platform rather than one tuned to a device family, so it applies to any compatible GKI device but carries none of the device specific configuration this repository holds. The Sultan entry is a separate kernel line from another author, credited to kerneltoast, and is a different codebase with different choices. The alternative to either is the obvious one: stay on the stock kernel. That trades away kernel level root, SUSFS hiding and the whole patch set, but it removes the bricking question entirely and keeps the vendor radio behaviour untouched. Choosing between them is mostly a device question rather than a feature question, and the table of OnePlus models is the input to that decision. ## Recent cadence, and no licence to point at The release history shows three builds tagged v2.2.0-r2, r3 and r4 between June and August 2026, and the last push was on 2026-10-20, so commits continue after the most recent tagged release even though no new tag has appeared since. The readme names the upstream projects the work builds on and how to reach the maintainer, including issue reports and a Telegram group. One gap is worth flagging plainly: the project listing carries no licence identifier, and the readme's own text covers donations and attribution rather than reuse terms. If your organisation intends to redistribute, vendor or audit the kernel source, that question needs an answer from the maintainer before anything else in this review matters, because the absence of a stated licence says nothing about what you may actually do with it. ## Conclusion Adopt it if your exact model is listed in compatibility.md and you already know how to flash a GKI kernel and recover from a failed flash. Do not adopt it on an unlisted device, on a phone you cannot reflash, or if root detection by apps is not a problem for you. Check the compatibility file first, then read the installation instructions inside the release notes before starting, since the readme itself carries no commands and the tracker's two hour update cycle means upstream can move faster than any published build. ## FAQ ### Which OnePlus devices does OnePlus_KernelSU_SUSFS support? The readme tells you to verify device compatibility before flashing and points to the compatibility.md file in the main branch for the list. Nothing in the project listing substitutes for that file. ### Will flashing this kernel void my warranty? The readme states that flashing the kernel will not void your warranty, but warns that there is always a risk of bricking the device and advises backing up your data first. ### What does SUSFS add to this kernel? SUSFS is described as an addon root hiding kernel patch set with a userspace module for KernelSU. The project also supports the WildKSU Manager, a root manager from the same team. ### Where can I find the installation steps for this kernel? The readme contains no commands. It directs GKI users to the official KernelSU Installation Guide and notes that installation instructions are also found in the release notes, with KernelFlasher listed as an additional resource. ### How often does the project check upstream OnePlus kernel changes? A live tracking dashboard is hosted in the repository at status-page/README.md, and the readme states its update frequency is every two hours, automated. ## Sources - [Issues](https://github.com/WildKernels/OnePlus_KernelSU_SUSFS/issues) - [README](https://github.com/WildKernels/OnePlus_KernelSU_SUSFS/blob/main/README.md) - [Releases](https://github.com/WildKernels/OnePlus_KernelSU_SUSFS/releases) - [WildKernels/OnePlus_KernelSU_SUSFS on GitHub](https://github.com/WildKernels/OnePlus_KernelSU_SUSFS) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wildkernels-oneplus-kernelsu-susfs