TL;DR: A KernelSU patch hunk failed because the target kernel source does not match the patch’s expected lines. Use the exact source revision for your firmware, confirm the correct KernelSU patch, and run a dry check. Inspect any .rej file before rebuilding. Never flash a kernel with unresolved rejects.
By the PrivacyPortal team
Last updated August 2026.
The message “Hunk #1 FAILED” comes from the patch tool, not KernelSU itself. It means the tool found the target file but could not match the surrounding code. The usual cause is an old manual-hook patch, a different OEM kernel revision, or a tree that was already changed. The .rej file contains the part that was not applied. A KernelSU patch hunk failed error is therefore a source-matching problem. It is not fixed by repeatedly running the patch or ignoring the rejected lines. Back up your phone and source tree first. Unlocking the bootloader wipes user data. A bad kernel can stop the device booting and may affect security, updates, warranty support, banking apps and Play Integrity.
A rejected KernelSU hunk beside the source lines it expected to find.
What “Hunk #1 FAILED” and .rej files mean
A patch is a set of changes with context lines around each change. Those context lines tell the patch tool where to insert or remove code.
“Hunk #1” means the first change block for that file. “FAILED” means no safe matching location was found. The tool then writes the rejected block to a file ending in .rej. For example, a failure against kernel/cred.c may create kernel/cred.c.rej.
A .rej file contains a change block that the patch tool could not place safely in the target source file.
The original file may still contain other applied hunks. This creates a partly patched tree. That state is dangerous because a build can sometimes complete despite missing a required hook.
Do not treat a successful compile as proof of a correct KernelSU integration. Resolve every reject, review the resulting diff and test the kernel on a device with a known recovery path.
Why a KernelSU patch hunk failed
The most common cause is a revision mismatch. Android vendors often publish several kernel branches for one device family. Small changes in an OEM update can move or rename the code around a KernelSU hook.
Other common causes include:
- The patch targets another KernelSU release or fork.
- The source does not match the firmware currently installed.
- A previous patch attempt changed some target files.
- The patch has already been applied.
- Line endings or whitespace were changed by another tool.
- An OEM backport changed a function without changing the Linux version.
- The wrong strip level made the patch target an incorrect path.
The displayed kernel version is not enough to prove compatibility. Two kernels labelled 5.10 can contain very different OEM commits. Compare the repository, branch, commit and Android security update as a set.
Manual hooks are sensitive to source changes
KernelSU manual hooks alter specific kernel paths. They are useful for non-standard kernels, but their context can become stale quickly.
A patch written for an older task_work, credential or permission path may not fit a vendor backport. Blindly removing context until the patch applies can put a hook in the wrong function.
Use the official KernelSU non-GKI integration guide for the release you selected. Do not mix instructions from KernelSU, KernelSU Next, SukiSU Ultra or RKSU. These projects share concepts but may require different patches and build settings.
Choose the safest recovery path
| What you find | Likely cause | Best next action |
|---|---|---|
| Reverse check succeeds | Patch is already applied | Do not apply it again; inspect the existing diff |
| All hunks fail in many files | Wrong source or strip level | Confirm the branch, paths and patch origin |
| One hunk fails after an OEM update | Nearby vendor code changed | Port that hunk carefully or use a matching revision |
| Tree has unrelated edits | Patch context was disturbed | Start from a clean worktree and reapply changes |
| No matching source is available | Vendor source gap or unsupported kernel | Stop; use a supported method or remain unrooted |
The lowest-risk fix is usually a clean, exact source checkout. Manual porting is suitable only when you can review C code and trace the changed call path.
A decision table for separating an already-applied patch from a true source mismatch.
How to fix the failed KernelSU patch safely
Use this numbered workflow on your own device’s kernel source, before creating or flashing any boot image.
- Back up the phone, including authentication data and anything not synced elsewhere. Keep the factory boot image and full firmware package.
- Record the installed firmware build, kernel version and Android security update. Obtain the vendor’s matching kernel source rather than a nearby release.
- Create a clean Git branch for the integration. Run git status --short and save any existing work before continuing.
- Download the official KernelSU v3.2.5 source or the exact release required by your kernel. Use the corresponding patch or documented setup method from the files section.
- Run git apply --check path/to/kernelsu.patch. This checks the patch without changing the tree.
- If the check fails, run git apply --reverse --check path/to/kernelsu.patch. A successful reverse check usually means the change is already present.
- Run git apply --reject --verbose path/to/kernelsu.patch only on the disposable branch. This applies safe hunks and creates .rej files for inspection.
- Find rejects with git status --short and search for files ending in .rej. Compare each rejected block with the current function.
- Use the correct source or port the change deliberately. Delete no .rej file until its intended change is present or proven unnecessary.
- Review with git diff, build using the vendor toolchain, and verify the output before flashing. Stop if any reject or unexpected edit remains.
Prerequisites before you start
You need the exact kernel source, its build configuration and a compatible compiler toolchain. You also need Git, a patch utility, enough storage and basic knowledge of Android boot images.
Keep a second device or computer available. Confirm that fastboot, download mode or the vendor recovery route works before changing the phone.
KernelSU v3.2.5 was the latest stable release on 20 August 2026.
Version alignment matters. A newer manager application does not make an older or incomplete kernel patch compatible.
How to inspect and port a rejected hunk
Open the .rej file and its target source file side by side. The lines beginning with a minus sign describe expected old code. Lines beginning with a plus sign describe the intended change.
Find the current version of the surrounding function by name. Then establish why it changed. A renamed variable may need a small edit. A redesigned security path may require a different hook or make the patch unsuitable.
Do not paste added lines into the nearest similar function. Check types, locking, error paths and conditional compilation. Kernel code can compile while introducing a crash or privilege flaw.
If you cannot explain the whole hunk, move to the exact supported source revision. That is safer than guessing.
How to verify the repaired integration
First, confirm that no .rej files remain. Run git diff --check to catch whitespace errors. Review every changed file against the selected KernelSU release.
Build once from a clean output directory. Save the compiler log and confirm that the expected kernel, modules and boot image were produced. Warnings near the edited code deserve review even when compilation succeeds.
Before flashing, unpack or inspect the output with the same tools used by your device’s normal build process. Confirm the kernel format, compression and boot-image header match the factory image.
After flashing, check all of these:
- The phone completes a cold boot without a boot loop.
- KernelSU Manager reports the expected kernel integration and version.
- Wi-Fi, mobile data, camera, storage and charging still work.
- SELinux remains enforcing unless the documented build requires otherwise.
- The device can reboot to bootloader or recovery.
A root prompt alone is not full verification. Test normal device functions before adding modules.
KernelSU Manager confirming the expected kernel integration after a clean boot.
Flashing and recovery risks
Unlocking the bootloader normally erases the phone. Android requires this wipe to protect data from an unauthorised unlock. Read the Android bootloader locking and unlocking guidance before starting.
Android’s bootloader guidance requires user data to be erased when a device changes from the locked state to the unlocked state.
Never relock a bootloader while a modified or incompatible image is installed. The device may refuse to boot, and recovery can become harder.
A custom kernel may also change OTA behaviour. An update can overwrite the patched image or fail its verification checks. Keep the stock image that matches the installed build.
Root may reduce device security if access is granted carelessly. It can also trigger banking, streaming, workplace or Play Integrity checks. No KernelSU method can be promised to pass a specific app’s checks. Detection changes on both the app and platform sides.
Common fixes that make the problem worse
- Using a force option: Forced placement cannot prove that the chosen function is correct.
- Changing the hunk line number: The line number is only a hint. Context and code meaning matter more.
- Deleting .rej files: This hides evidence without applying the missing change.
- Building a partly patched tree: A successful build may still contain a broken integration.
- Mixing root families: A Magisk-patched boot image is not a KernelSU kernel integration.
- Copying another device’s boot image: Similar model names do not prove image compatibility.
- Adding hiding modules immediately: Extra changes make boot faults and detection issues harder to isolate.
In practice, the fastest reliable fix is often to discard the test branch. Start again from the correct vendor commit and one documented KernelSU release.
KernelSU, forks and alternative approaches
KernelSU and its forks provide kernel-space root, but they are not interchangeable build targets. KernelSU Next, SukiSU Ultra and RKSU can differ in supported kernels, hooks and SUSFS integration.
GKI means Generic Kernel Image. Suitable GKI devices may support a documented KernelSU installation without manually patching vendor source. Older or heavily changed kernels often need a device-specific build.
APatch also works at the kernel level but uses a different patch and module model. Magisk normally patches a boot image and uses its own userspace framework. Moving to another root family is a fresh integration decision, not a way to reuse a failed KernelSU patch.
If you prefer a maintained setup, a supported privacy-focused device can remove much of this build work. PrivacyPortal’s privacy-first Android phones are configured for users who value control without maintaining a custom kernel.
Further PrivacyPortal guides
New flashers should begin with our guide to Android bootloader unlocking. It explains the data wipe, recovery planning and relocking risks.
For a wider view of root choices, read our practical guide to rooting Android safely. It covers backups, boot images and the trade-offs between common root managers.
Frequently asked questions
Can I ignore “Hunk #1 FAILED” if the kernel compiles?
No. Compilation only proves that the remaining source is syntactically buildable. It does not prove the missing KernelSU hook was optional or placed elsewhere. Resolve every reject and review the complete diff before flashing.
Why did the same patch work on another phone?
The other phone may use a different vendor branch, kernel commit or backport set. Even devices with the same Linux version can have different functions and security changes. Match the full firmware and source revision.
Does a .rej file damage the original source?
The .rej file itself does not. However, the patch tool may have applied other hunks before writing it. Check git diff and git status --short to identify the partly applied changes.
How do I know whether the patch was already applied?
Run git apply --reverse --check path/to/kernelsu.patch on a clean tree. If that succeeds, the patch can be reversed and is probably already present. Still inspect the history and diff before relying on it.
Will fixing the patch make banking apps work?
No such promise is possible. A correct KernelSU integration only addresses kernel functionality. Apps can inspect bootloader state, system properties, installed software, device integrity and other signals. Their checks can change without notice.
What should I do if KernelSU patch hunk failed again?
Stop patching the altered tree. Return to a clean branch, verify the vendor commit and select the matching KernelSU integration method. If the source is unsupported or incomplete, use a supported kernel or keep the stock configuration.
Modules, apps & files to try
Here are the actual tools the rooting community uses for this, each linked to its official source. They're third-party community projects, so download only from the official page below, back up your boot.img first, and follow each project's own instructions. PrivacyPortal isn't affiliated with these projects and can't guarantee third-party files — flash at your own risk.
| File | What it is & how to use it safely |
|---|---|
| Magisk (GITHUB) | The original and most widely used Android root manager; systemless root via boot-image patching, with built-in Zygisk, a module system and a DenyList for hiding root. Download ONLY from the official repo github.com/topjohnwu/Magisk — its README states GitHub is the sole official source, and third-party "Magisk Manager" sites/APKs are frequently repackaged with malware. Rooting trips Play Integrity and can brick a device: back up your stock boot.img before patching/flashing, and never flash a Magisk ZIP/APK obtained from a Telegram link or random mirror. |
| KernelSU (GITHUB) | The original kernel-based root manager — implements root as a kernel module rather than patching the boot ramdisk like Magisk; needs a GKI 2.0 or KernelSU-supported kernel. Official open-source (GPL) project, actively maintained — latest KernelSU v3.2.4 (Apr 2026). Kernel-level root requires a GKI 2.0 / kernel 5.10+ device (older 4.14+ kernels need a manually built kernel). Only download from the official GitHub Releases page (github.com/tiann/KernelSU/releases), never a Telegram link or mirror; verify the .apk/kernel matches your exact device and back up your boot.img before flashing, as a bad kernel image can bootloop the device. The companion KernelSU-Next fork (github.com/KernelSU-Next/KernelSU-Next) is also legitimate and supports wider kernel ranges (4.4–6.6). |
| APatch (GITHUB) | Kernel-level Android root manager that patches the kernel image directly and provides its own KPM (Kernel Patch Module) system; an alternative to Magisk and KernelSU. APatch is a legitimate open-source, kernel-level root manager (built on KernelPatch; UI/module code derived from KernelSU). Only download the APK from the official GitHub Releases page (github.com/bmax121/APatch/releases) or the official docs at apatch.dev — avoid third-party APK mirrors. Because it patches the kernel directly, ALWAYS back up your boot.img before flashing, and choose a strong SuperKey: the SuperKey has higher privileges than root, so a weak or leaked key can hand full control of your device to an attacker. Rooting voids warranties, can trip banking/Play Integrity checks, and a bad patch can bootloop the device. |
| SUSFS (GITLAB) | Kernel-level filesystem-hiding patch (VFS layer) that hides root-related files and mounts from apps; requires kernel support and is applied via the patched kernel. SUSFS is a kernel-level patch, not a one-click app — it requires a SUSFS-patched kernel, so back up your boot.img/stock kernel before flashing and only use the official simonpunk GitLab repo or a reputable pre-patched kernel. Upstream calls it experimental; a bad flash can bootloop your device. |
PrivacyPortal sells ready-to-use, de-Googled GrapheneOS Pixels — hardened, kept updated, and shipped with our encrypted Graphite messenger. Browse privacy phones →
