KernelSU Hook Failures: GCC Folding on Linux 3.x

TL;DR: Most kernelsu hook failures on Linux 3.x are not caused by GCC identical code folding. GCC added IPA-ICF in version 5. Many Android 3.x kernels use GCC 4.9. Check the real compiler, symbols, optimisation, kprobes and vendor source. Treat any fix as an experimental backport.

By the PrivacyPortal team

Last updated August 2026

KernelSU needs reliable places inside the kernel where it can intercept security-relevant calls. On an old Linux 3.x Android kernel, those places may be missing or changed. A vendor may have renamed a function. The compiler may inline it. Kprobes may also be incomplete. The correct fix depends on which failure occurred. It is not safe to blame “GCC folding” without checking the compiler and final kernel image.

Back up your phone before changing anything. Unlocking the bootloader wipes user data. A bad boot image can leave the device unable to start. Root may also affect warranty support, over-the-air updates, banking apps and Play Integrity results.

Why kernelsu hook failures are misdiagnosed

The phrase “function folding” covers several different compiler actions. Identical Code Folding merges functions that have equivalent code. GCC calls its interprocedural form IPA-ICF. GCC introduced that optimisation in GCC 5.

GCC 5 introduced interprocedural identical code folding through the -fipa-icf option.

That date matters. Many Android devices with Linux 3.4, 3.10 or 3.18 kernels were built with Android GCC 4.9. That compiler does not have GCC 5’s IPA-ICF pass. A kernelsu gcc function folding diagnosis is therefore wrong when the build really uses GCC 4.9.

Confirm the compiler instead of relying on a ROM post. Run adb shell cat /proc/version. Also inspect the build log and invoke gcc --version inside the toolchain. GCC’s official optimisation option documentation explains the passes supported by each maintained release.

A compiler report, kernel build string and symbol table give a stronger diagnosis than the phone’s model name alone.

What can look like identical code folding

Ordinary optimisation can still change a hook target. A small function may be inlined into its callers. A tail call may become a direct branch. A static function can disappear when nothing uses it.

Link-time optimisation may reshape larger parts of the image. Vendor patches can also change a function’s signature or make it private. These outcomes are real even when IPA-ICF is impossible.

A missing name is not proof that the function vanished. Android kernels often restrict exported symbols. A stripped image may lack the names shown in vmlinux. Kernel address randomisation can make runtime addresses differ too.

Inspect both the unstripped vmlinux and the packed kernel placed in boot.img. Use nm, readelf and objdump. This shows whether code exists and how callers reach it.

KernelSU hook failures compared

Observed failure	Likely cause	Best first check	Typical response
Target absent from vmlinux	Inlining, dead-code removal or vendor source changes	Disassemble its callers	Choose a stable target or make a narrow source change
Symbol exists but kprobe registration fails	Broken kprobes, blacklist rules or unsupported instruction placement	Review CONFIG_KPROBES and boot logs	Repair kprobes or use a compatible hook method
ARM64 branch patch cannot be installed	Range, instruction layout or validation failure	Read the branch-hook diagnostic	Use the supported syscall-table fallback
Kernel boots but root never appears	Wrong manager, daemon mismatch or inactive hook	Check manager version and dmesg	Match the kernel integration and manager lineage
Device bootloops after flashing	Wrong image, ABI mismatch or early hook crash	Restore the known-good image	Rebuild from the exact vendor source and configuration

This table prevents a broad compiler theory from hiding a more direct fault. In practice, vendor source drift and weak kprobe support are common on old Android kernels.

How to diagnose and rebuild a legacy KernelSU kernel

This workflow tests the cause before you modify or flash your own device.

1. Back up photos, messages, app data and authentication recovery codes. Keep the factory image on another computer.
2. Record adb shell uname -a, adb shell cat /proc/version and the current build number.
3. Obtain the exact vendor kernel source, matching defconfig and matching boot image. A similar device tree is not enough.
4. Install Android SDK Platform-Tools and the compiler required by that source. Record the exact compiler output.
5. Build an unchanged baseline kernel first. Do not debug KernelSU until the vendor source can reproduce a booting image.
6. Inspect .config for kallsyms and kprobe support. Compare it with the configuration exposed by the running device.
7. Search unstripped vmlinux for each proposed hook. Disassemble its callers when a symbol is absent.
8. Apply the KernelSU backport intended for that kernel tree. Resolve each rejected patch against the vendor implementation.
9. Build a new boot image. Test with fastboot boot only if the device supports temporary booting.
10. Verify the boot log, KernelSU manager state and root access. Stop if the log shows a hook or memory fault.

Prerequisites and files

You need an unlocked bootloader, a full backup and a tested recovery route. Unlocking normally erases the phone. Follow the device maker’s process and the Android bootloader locking and unlocking guidance.

Use a reliable USB cable and current Android SDK Platform-Tools. You also need the precise factory boot image, vendor kernel source and defconfig. The compiler should match the vendor build unless the source documents another supported toolchain.

Install the manager APK made for your chosen KernelSU lineage. Standard KernelSU, KernelSU Next, SukiSU Ultra and RKSU are related projects. Their managers and kernel components are not interchangeable by assumption. Use the named items supplied in the “Modules, apps & files to try” section where available.

The official KernelSU non-GKI integration guide is useful background. It does not make Linux 3.x an officially supported target.

Verification after the first boot

Start with adb devices. Confirm that Android finishes booting and keeps a stable USB connection. Then compare uname -a with the build you intended to install.

Open the matching KernelSU manager. It should recognise the kernel integration. A manager screen alone is not enough. Inspect dmesg for KernelSU hook errors, protection faults and daemon startup messages.

Test root with a harmless shell request. Grant access only to a trusted terminal app. Reboot once and repeat the check. Then test calls, cameras, storage and Wi-Fi before restoring sensitive apps.

Keep the original boot image ready. If a temporary boot fails, reboot to leave it. If you flashed the image, restore the known-good image using the device’s documented bootloader process.

A successful test includes a normal boot, clean kernel log, matching manager and working recovery route.

Understanding a KernelSU branch link failure

On ARM64, a branch-with-link instruction can redirect execution to a hook while saving a return address. It is compact and avoids some overhead. It still depends on the instruction site and destination being suitable.

A kernelsu branch link failure can occur when the target instruction cannot be patched safely. The destination might also be outside the valid branch range. A modified vendor function may not match the layout expected by the hook code.

KernelSU’s ARM64 branch-link hook implementation can fall back to syscall-table hooking when branch-link setup fails.

A fallback is not the same as a clean primary hook. It changes the path used to intercept a call. Review the source and logs for the precise build. The ARM64 branch-link hook source shows this fallback in a maintained fork.

Do not force a branch patch by skipping validation. A bad instruction patch can crash the kernel before Android starts.

Choosing KernelSU legacy kernel hooks

Kernelsu legacy kernel hooks must match the actual vendor tree. Function names from a modern common kernel may not exist in Linux 3.x. Even familiar names can have different arguments or call paths.

The search phrase “do execve common kernelsu” usually points to do_execve_common or a related execution path. Its presence is not guaranteed. Some kernels expose a wrapper. Others inline or restructure the work through vendor patches.

Start from the syscall entry and trace the calls in disassembly. Confirm the proposed target runs for both normal apps and the relevant compatibility path. Never patch a function just because its name appears in a different device’s guide.

Kprobes are attractive because they avoid a hard-coded address. Old Android implementations may be incomplete or disabled. A symbol can exist while its first instructions remain unsafe for probing.

Syscall-table hooking can work as a fallback in some backports. It brings its own risks. The table may be read-only, hidden or altered by vendor hardening. Choose the method supported by evidence from your built image.

A practical decision framework

• GCC 4.9 confirmed: rule out IPA-ICF. Check inlining, tail calls, symbol visibility and vendor differences.
• GCC 5 or newer confirmed: inspect build flags and optimisation reports. Do not assume IPA-ICF was enabled.
• Target exists: test whether the hook mechanism supports its address and first instructions.
• Target is absent: trace callers before changing optimisation. A renamed vendor path may be the real target.
• Baseline kernel does not boot: fix the source, config and packing process before adding KernelSU.
• No supported hook is stable: stop. Use another root approach or keep the device unrooted.

Linux 3.x is end-of-life. Current official KernelSU development does not support it as a normal target. A successful port remains tied to one source tree, compiler and configuration.

Any KernelSU implementation on Linux 3.x is an experimental, device-specific backport rather than a supported universal installation.

Pitfalls that waste the most time

• Using a Magisk-patched boot image as though it contained a KernelSU-enabled kernel.
• Building source for a close model instead of the exact device revision.
• Changing the compiler, optimisation flags and hook code in one build.
• Looking only at /proc/kallsyms on a restricted production kernel.
• Using a manager from another KernelSU fork.
• Disabling broad optimisation across the whole kernel to preserve one function.
• Flashing before an unchanged baseline image has booted successfully.
• Assuming a clean manager screen proves every hook works.

A narrow source change is easier to audit. For example, a targeted no-inline change can test an inlining theory. It should not become a universal fix. Compiler attributes differ, and a forced function boundary may affect security or stability.

Good diagnosis changes one variable per build and keeps the original boot image within reach.

Security, updates and app compatibility

Kernel root expands the impact of a malicious module or granted app. Review source where possible. Remove modules that are abandoned or ask for access unrelated to their purpose.

Root can break incremental over-the-air updates. An update may replace the boot image or load a different kernel. Restore the expected stock image before following the vendor’s update process.

Banking apps, payment apps and games use changing checks. Play Integrity is only one signal. No KernelSU fork, module or hiding method can promise access to a specific app. Test your required apps before relying on the phone for travel or payments.

Relocking a bootloader with a modified image can brick some devices. Return every verified partition to stock first. Follow the manufacturer’s instructions for the exact model.

If maintaining a legacy kernel is too risky, consider a supported device. PrivacyPortal’s privacy-first Android phones offer a simpler route for users who want less dependence on Google without maintaining a kernel backport.

Frequently asked questions

Does GCC folding cause every KernelSU hook failure?

No. GCC’s IPA-ICF arrived in GCC 5, while many Linux 3.x Android kernels use GCC 4.9. Inlining, tail-call optimisation, missing symbols, vendor patches and faulty kprobes can produce similar symptoms.

Can I disable optimisation to fix the hook?

Disabling broad optimisation is a poor first fix. It changes timing, size and code layout across the kernel. Prove which pass changed the target. Then test the narrowest source or per-file change possible.

Can current KernelSU be installed on a Linux 3.x phone?

Not as a supported general installation. It needs an experimental backport for the exact vendor source. You must build and test the kernel yourself. A prebuilt image from another model can brick the phone.

Will syscall-table fallback fix a branch-link failure?

It may provide a compatible path on some ARM64 builds. It is not guaranteed. The syscall table may be protected or unavailable. Confirm the fallback was installed and exercised through kernel logs.

Will a working KernelSU build pass banking checks?

Not necessarily. Apps can use their own root, boot state and integrity checks. Results change with app and system updates. Never depend on a root method to defeat a specific bank’s checks.

What should I do if the phone bootloops?

Stop repeated flashing. Enter the bootloader or documented recovery mode. Restore the known-good boot image for that exact build. If recovery paths do not work, seek model-specific help before writing more partitions.