KernelSU Patch Failed: How to Fix “Hunk #1 FAILED” and .rej Files

TL;DR: A “KernelSU patch hunk failed” message means the patch cannot find the expected source-code context. Stop before compiling, inspect the generated .rej file, confirm the kernel branch and patch revision match, check the application order and strip level, then rebase or manually port the rejected change against your exact kernel source.

The safest fix is not to delete the rejection file or force the build. A KernelSU “Hunk #1 FAILED” error usually points to the wrong kernel branch or commit, an incompatible patch variant, vendor-modified code, an already-applied change, incorrect patch order, or running the command from the wrong directory. Identify which condition applies, test the patch without changing the tree, and compile only after every intended hunk has been accounted for.

By the PrivacyPortal team

Last updated July 2026. This guide applies to people modifying their own Android devices and kernel source. Kernel branches, KernelSU forks and integration methods change, so treat the commit hashes and documentation shipped with your chosen project as authoritative.

What “KernelSU patch hunk failed” actually means

A patch is a set of proposed source-code changes. Each section, called a hunk, contains removed or added lines plus surrounding context. The patch tool searches the target file for that context. “Hunk #1 FAILED” means it could not find a sufficiently close match at the expected location.

The failure does not necessarily mean KernelSU is broken. It usually means the patch was created against source that differs from the tree on your computer. Even a small vendor edit, renamed function, changed header or earlier backport can prevent an exact match.

A message such as “saving rejects to file example.c.rej” creates a rejection file containing the diff fragment that was not applied. The .rej file is evidence: it shows what the patch expected to change. Deleting it may hide the warning, but it does not apply the missing code.

A .rej file contains the rejected diff fragment; it is diagnostic input for rebasing or manually porting the change, not a build artefact to delete and ignore.

Caption: A failed hunk beside its .rej file, with the unmatched context highlighted in the kernel source.

Why KernelSU patches fail

Likely cause	What you normally see	Best next check
Wrong kernel branch or commit	Several hunks fail across related files	Compare the patch’s intended base with git rev-parse HEAD and the vendor branch
Patch already applied	Added lines already exist, while forward application fails	Run git apply --reverse --check patch-file.patch
Wrong patch order	A later patch expects symbols introduced by an earlier one	Read the series, integration script or project instructions
Vendor-modified source	The correct function exists but its body or arguments differ	Compare the .rej context with the current implementation
Wrong directory or strip level	Errors say files cannot be found, despite existing in the tree	Inspect the patch paths and test -p0 versus the usual -p1
Wrong KernelSU variant	Patch paths or APIs do not match the selected manager or fork	Use only the integration files documented for that exact project revision
Damaged or transformed patch	Malformed-patch errors, missing headers or broken whitespace	Download the original raw patch again and verify its checksum if supplied

In practice, branch mismatch is the most common cause. Android manufacturers frequently publish multiple kernel repositories for one device family, then maintain separate branches for Android releases, regional models and firmware generations. Matching a device name is insufficient; the source revision must correspond to the firmware and kernel you intend to run.

Back up before patching or flashing

Creating a source-tree backup is easy; recovering an incorrectly flashed phone may not be. Save personal data first and preserve clean copies of the exact stock boot-related images for the installed firmware. Depending on the device, those may include boot, init_boot, vendor_boot and vbmeta. Do not assume an image from a similar build is interchangeable.

• Unlocking the bootloader normally performs a factory reset and wipes user data.
• Flashing an incompatible kernel or the wrong partition can cause a boot loop or an unbootable device.
• Bootloader unlocking and unofficial images may affect warranty support and over-the-air updates.
• Root changes the device security model. Grant superuser access only to software you trust.
• Banking, workplace and media apps may check bootloader state, Play Integrity or other signals. No configuration can be promised to pass a particular app’s checks.

Read our Android backup checklist before rooting and bootloader unlocking safety guide before touching a device with irreplaceable data.

How to diagnose and fix a failed KernelSU patch

Work in a version-controlled kernel tree on Linux or a supported Linux build environment. Use the patch and integration method supplied by the exact KernelSU project or fork you selected. The official KernelSU repository and its documentation should take precedence over copied commands from old forum posts.

1. Record the exact starting point. From the kernel source root, run git status --short, git rev-parse HEAD and git branch --show-current. Save the output with the device model, firmware build and patch source. If the tree already contains unrelated changes, create a separate clean clone or worktree before continuing.
2. Confirm the integration route. Check whether the device uses a supported Generic Kernel Image approach, a non-GKI integration, a prebuilt kernel or a fork-specific method. Do not apply a KernelSU patch to a Magisk-patched boot image: KernelSU integration changes the kernel, whereas Magisk’s conventional installation patches a boot-related image.
3. Inspect the patch paths. Open the patch as text. Paths beginning with a/ and b/, such as a/fs/exec.c, normally imply applying it from the kernel root with strip level -p1. A patch containing paths relative to the root without those prefixes may require -p0.
4. Perform a non-destructive check. For a Git-formatted patch, run git apply --check patch-file.patch. For a traditional patch, use patch --dry-run -p1 < patch-file.patch. A dry run reveals path and context problems without partially editing the source.
5. Check whether it is already present. Run git apply --reverse --check patch-file.patch. If the reverse check succeeds, the change may already be applied. Verify the relevant code and commit history rather than applying it twice.
6. Verify the base revision and order. Find the commit, tag or kernel branch named by the patch author. Apply prerequisite patches in their documented order. Avoid mixing patches from KernelSU, KernelSU Next, SukiSU Ultra, RKSU or another lineage merely because filenames look similar; their kernel requirements and APIs can diverge.
7. Generate and inspect rejects deliberately. If you need to see partial results, do so only in a disposable clean tree. git apply --reject patch-file.patch applies matching hunks and writes rejected ones to .rej files. Immediately review git diff so you know exactly what changed.
8. Compare each .rej file with the target. The rejection shows removed lines prefixed with a minus and proposed additions prefixed with a plus. Locate the corresponding function or data structure in the current source. Search by function name or distinctive symbols, not only by the rejected line number, because line numbers drift between branches.
9. Rebase or port the change. If the same logic exists in a different location, adapt the intended change to the current function signature, locking rules, configuration guards and error paths. Do not paste a hunk blindly. Kernel APIs may have changed in ways that make the old code unsafe or semantically wrong.
10. Account for every rejection. After editing, rerun the dry check where applicable, inspect git diff --check for whitespace errors, and confirm that no .rej file represents an omitted requirement. Remove a .rej file only after its change has been correctly applied, replaced, or proven irrelevant with a documented reason.
11. Build and verify before flashing. Use the vendor’s documented compiler and configuration, then review the complete build log. Confirm the output belongs to the intended device and partition packaging method. After flashing, verify that Android boots, the kernel version is expected, KernelSU Manager recognises the kernel integration, and ordinary device functions remain stable.

The automatically appended “Modules, apps & files to try” section should be used only for files matching your selected KernelSU lineage and kernel revision. A manager application cannot compensate for an incompatible kernel patch.

Caption: A safe workflow moving from a clean commit through dry-run validation, manual porting, compilation and on-device verification.

How to read a .rej file without guessing

A rejection file should be read alongside three sources: the original patch, the current target file and the commit history. Start with the function surrounding the rejected fragment. Determine the purpose of the change: adding a hook, exporting a symbol, changing credentials, modifying build configuration or wiring a new source directory into the build.

Next, identify why the context differs. If only comments or nearby lines changed, a careful manual port may be straightforward. If function parameters, types, locking or control flow changed, find a newer upstream implementation or a patch explicitly rebased for that branch. Those differences can carry security consequences that a successful compilation will not expose.

The official git apply documentation explains checks, reverse application, three-way merging and rejected hunks. Three-way application can help when a Git patch contains suitable blob information, but any resulting conflict still requires human review.

The Git documentation states that git apply --check tests whether a patch is applicable without applying it to the working tree.

When manual porting is reasonable

Manual porting is reasonable when you understand the affected kernel subsystem, can explain the rejected change, and have a reproducible recovery path. A one-line build-system path change is very different from a conflict inside credential handling, process execution or filesystem code.

Stop and obtain a branch-specific patch when:

• many unrelated hunks fail;
• the expected functions do not exist;
• the patch targets a different major kernel line;
• security-sensitive logic has substantially different control flow;
• the source release does not match the device firmware;
• you cannot identify what the rejected code is intended to accomplish.

The Android kernel architecture documentation provides useful context on GKI, kernel modules and Android’s kernel model.

The official KernelSU integration guidance distinguishes GKI installation from non-GKI kernel integration; choosing the wrong route is not fixed by forcing rejected hunks.

KernelSU, forks and patch compatibility

KernelSU and forks such as KernelSU Next, SukiSU Ultra and RKSU belong to the same broad kernel-root ecosystem, but they are not one interchangeable patch set. Forks may introduce different hooks, manager expectations, module features or SUSFS integration. Always match the kernel patch, userspace manager and any companion module to the same documented lineage.

SUSFS is kernel-level filesystem-hiding functionality, not merely an ordinary root-hiding module. Its companion module communicates with functionality that must already exist in a compatible kernel. Adding an SUSFS userspace module cannot repair a failed or absent kernel patch.

Root concealment is also separate from patch correctness. A kernel that compiles and boots may still be detected by apps, and concealment changes can themselves introduce compatibility or security problems. PrivacyPortal does not promise that KernelSU, SUSFS or any module will satisfy a particular bank, workplace policy or Play Integrity verdict.

Caption: Kernel patch, matching manager and optional companion modules shown as separate compatibility layers.

Pitfalls that turn a patch error into a broken build

• Deleting .rej files immediately: this removes the clearest record of missing code.
• Using fuzz as proof of compatibility: a patch tool may accept nearby context while placing a change incorrectly.
• Continuing after partial application: dependent hunks can leave the tree internally inconsistent.
• Mixing fork instructions: similarly named projects may expect different kernel changes.
• Testing on the only copy of the source: a clean Git tree makes comparison and rollback practical.
• Flashing because compilation succeeded: compilation does not prove device compatibility, correct partition packaging or runtime safety.
• Using the running kernel version alone: a version string does not identify all vendor commits and backports.

Frequently asked questions

Can I delete the .rej file and compile?

Only after you have reviewed and resolved the rejected change. Deleting the file does not add the missing code. A build may still compile while lacking a required hook or configuration change, leaving KernelSU incomplete or unsafe.

Does “Hunk #1 FAILED” mean I used the wrong strip level?

Sometimes. “File not found” messages strongly suggest the working directory or strip level is wrong. If the correct file is found but its context does not match, a branch, revision, patch-order or vendor-source mismatch is more likely.

Should I use git apply --3way?

It can help when the patch includes appropriate Git blob information and the original base is available. It is not an automatic compatibility converter. Review every merged change and conflict, especially in security-sensitive kernel code.

Can I apply a KernelSU patch to a Magisk-patched image?

No. Conventional Magisk installation modifies a boot-related image, while KernelSU requires compatible kernel integration. Start from the correct stock source and images for the chosen KernelSU method rather than treating the two patch formats as interchangeable.

Will fixing the patch make banking apps work?

No guarantee is possible. Patch success only shows that source changes were applied. Apps may evaluate bootloader state, root artefacts, Play Integrity results, device certification and proprietary signals that change without notice.

What should I do if every hunk fails?

Stop and verify the patch’s intended repository, branch, commit and KernelSU lineage. When every hunk fails, manual editing is rarely the sensible first response; the patch is probably for materially different source.

Is a successful build enough to flash?

No. Confirm the device codename, firmware base, output format, target partition and recovery procedure. Keep exact stock images available, back up personal data, and never flash an image merely because the compiler produced it.