susfs4ksu-lkm by inforcqb ports SUSFS to a loadable kernel module (LKM). Until now susfs had to be patched into the kernel source, so you needed a custom kernel. Here the same features load into a stock GKI kernel at boot through KernelSU, on arm64 phones from kernel 5.10 up to 6.18.
Kernels it covers
Each release has one .ko per kernel interface (KMI). The name describes your kernel branch, not the Android version you run: a phone that launched on Android 13 with kernel 5.15 uses android13-5.15 even after an Android 15 update. Check yours with cat /proc/sys/kernel/osrelease.
| KMI | Kernel branch |
|---|---|
android12-5.10 | Android 12, kernel 5.10 |
android13-5.10 | Android 13, kernel 5.10 |
android13-5.15 | Android 13, kernel 5.15 |
android14-5.15 | Android 14, kernel 5.15 |
android14-6.1 | Android 14, kernel 6.1 |
android15-6.6 | Android 15, kernel 6.6 |
android16-6.12 | Android 16, kernel 6.12 |
android17-6.18 | Android 17, kernel 6.18 |
What the module zip does
The easiest way in is the module zip, which carries all eight .ko files and picks the right one. From its scripts:
- The installer stops unless it runs in a KernelSU-compatible manager (Magisk is refused) on an arm64 device.
- It reads the real kernel release from
/proc/sys/kernel/osreleaseand matches it against the packaged KMIs. A custom kernel without an Android tag only matches when its version maps to a single KMI, so 5.10 and 5.15 kernels without a tag are refused instead of guessed. - On every boot,
load.shloads the matching file withsusfs_insmod … expose_proc=1. It skips loading in safe mode, when the module is disabled, or when susfs is already there (/proc/susfs_pathor/sys/module/susfs_guard_lkm), so it never stacks on top of a kernel with built-in susfs. - It writes a log to
/data/adb/modules/susfs_guard_lkm/load.log. - It's a loader only. No susfs rules are applied; your manager or config tool does that through the
/proc/susfs_*nodes.
Installation
- Flash
susfs_guard_lkm-module-…-arm64.zipin your KernelSU-compatible manager. - Reboot. Nothing is loaded during the install itself.
- Check
load.login the module folder. Don't rely onlsmod: susfs can hide its own module.
Early loading
By default the module loads at the normal module post-fs-data stage. If susfs rules or original kstat snapshots have to be in place before other modules mount, switch to the earlier common stage:
touch /data/adb/modules/susfs_guard_lkm/early_loadReboot to apply. The installer puts a small dispatcher at /data/adb/post-fs-data.d/00-susfs-guard-lkm.sh for this; it refuses to overwrite a different script already at that path. Delete early_load and reboot to go back. Upgrades keep the setting, and uninstalling removes only the dispatcher.
Loading a .ko by hand
You can also grab the single .ko for your KMI from the release page and load it yourself:
# KernelSU
ksud insmod /data/adb/loader/susfs_guard_lkm.ko
# without KernelSU, using the release's loader
susfs_insmod /data/adb/loader/susfs_guard_lkm.ko
# unload
rmmod susfs_guard_lkm