# SUSFS bring-up: source and artifact audit, 2026-09-16 Status: **superseded for boot outcome** by [007-lab-results-20260916.md](007-lab-results-20260916.md) — matched DEBUG boot + vendor (correct SELinux) **booted**; SusFS v1.5.5 + Manager 35153 verified. This audit retains the ABI / stub / UAF analysis. Banking PASS still FAIL. LAB only; GOLDEN was not accessed. ## Verified baseline and build LAB reports `23.2-20260915-UNOFFICIAL-sunfish`, slot `_a`, kernel `4.14.357-openela-g28f9290ae067-dirty #1 ... Sep 15 18:06:17 UTC 2026`. Approved shell root works. The installed vibrator module probes successfully on this kernel. The DEBUG build started at `2026-09-16T11:51:15Z` and was still linking with `ld.lld` using a full CPU at 12:18Z. Ninja's idle-output warning alone is not a stalled-build diagnosis. Its inputs were not edited during this audit. ## Confirmed incompatible vendor module The installed `/vendor/lib/modules/drv2624.ko` imports `module_layout` with CRC `0xbce8f094`. The SUSFS sigfix build's `Module.symvers` exports it as `0xf9adc508`. There are **31 mismatches among 56 imports**. The matching module in the host output passes all 56 checks against that same symvers. Evidence was captured before DEBUG replaced these outputs: - Host symvers mtime: `2026-09-16 11:44:39 UTC`. - Host vendor module mtime: `2026-09-16 11:45:48 UTC`. - Kernel config: `CONFIG_MODVERSIONS=y`, module force loading disabled. - Device module loading list: `device/google/sunfish/init.insmod.sunfish.cfg` includes `drv2624.ko` alongside audio, touch and WLAN modules. - Local evidence: `.local-artifacts/007-kernelsu/rca-20260916/`, including `Module.symvers-sigfix`, `drv2624-installed.ko`, `drv2624-built.ko` and CRCs. Reproduce with `python3 scripts/check-module-abi.py `. Exit 1 means incompatible or unverified; exit 0 verifies CRCs only, not full ABI/CFI/firmware compatibility or device behaviour. **Implication:** flashing a SUSFS boot while retaining these installed vendor modules is an invalid release combination. Rebuilding modules on the host does not update the phone's vendor partition. The older vibrator watchdog is consistent with this defect, but historical dmesg or a controlled test is still needed to prove that particular attempt's cause. This result does not prove the cause of the subsequent early panics. SUSFS currently changes `task_struct` and `vfsmount`; those changes can affect layouts and transitive exported symbol CRCs. Do not bypass version checks. Package a consistent kernel/modules set and verify all imports before testing. After vendor changes, the old boot alone is not necessarily a valid rollback; preserve the corresponding old vendor/ROM and slot state too. ## Confirmed filename lifetime defect Our `fs/exec.c:do_execveat_common()` calls `__do_execve_file()`, which calls `putname(filename)` on both successful and failed exec paths. The wrapper then calls `ksu_handle_post_execveat()`; ReSukiSU dereferences `filename->name`. This is a use-after-free in the integration. It also exists in the root-only path, so its existence does not establish why only SUSFS panics in the recorded trials. Prepared patch: `vendor/sunfish/patches/007-kernelsu/0001-exec-avoid-post-hook-filename-uaf.patch`. It calls `ksu_handle_post_execve()` with NULL filename, which that handler explicitly supports for its LSM adapter. The patch is staged locally, not applied to the running build, and still needs compilation and LAB validation. ## Confirmed incomplete and mismatched SUSFS API The active kernel advertises SUSFS **v1.5.5**, based on upstream `kernel-4.14` at `77905b5a071e6f3669e3b1814cea30147c0801da` (February 2025), plus local compatibility wrappers. It is not a complete modern backport. The active `fs/susfs.c` contains: - `susfs_add_sus_map()`: reports success without implementing map hiding. - `susfs_set_avc_log_spoofing()`: reports success without the SELinux hook. - `susfs_add_sus_path_loop()`: aliases a one-time addition, with no loop list. - `susfs_run_extra_works()` and `susfs_start_sdcard_monitor_fn()`: no-op. - `susfs_get_enabled_features()`: returns only the generic KSU_SUSFS string. The local `st_susfs_sus_path` starts with `err`, then `target_ino`, then a pathname. Modern upstream v2.3.0 starts with the pathname, then `err`. Sharing command numbers or converting a pointer type does not make those wire formats compatible. Do not interpret compile/link success or a manager feature badge as proof that the commands work. [ReSukiSU integration documentation](https://resukisu.org/guide/build.html) explicitly directs non-GKI SUSFS integrators to backport the 5.10 patches. Its separate SUSFS hook mode is deliberate; the Kconfig choice is not in itself an upstream bug. Missing manual hooks when selecting SUSFS means the SUSFS integration must provide its own complete hook path. ## Upstream freshness checked without changing live inputs Remote refs were queried directly on 2026-09-16: - Latest ReSukiSU tag seen: `v4.2.0-rc2`, `3576e6a5255fc880c00f6a3175d89268a6d942be`. - Active ReSukiSU: `6d674e50a022a85076dcfe4498af9a8bfead2cf9`, nine commits after that tag, non-shallow, rev-list count 4453, computed version 35153, with local patches. Manager binary matching still requires independent verification; the filename is not sufficient. - Latest observed SUSFS 5.10 branch: `e466df60670eab2847ea76940be2f8a125c8adc9`, advertising **v2.3.0**. - Remote 4.14 branch still points to the old v1.5.5 commit above. - Abu reference checkout `ksu-susfs-23.0` is `8c604af9d3d97a8b1b2da1b663a4e39b32697e5a`, with SUSFS **v1.5.12**. This checkout is not proof of the exact source/configuration of the owner's working L22 binary. Do not conflate the two. Before a new build, fetch tags, record full revisions and version codes, and use a matching manager and userspace tool. A v2.3.0 port must include actual implementations, correct struct layouts and all call-site adaptations. ## Panic evidence remains missing The known-good dmesg shows the ramoops script exits 0, but inspection shows that the script returns the final key-generation command's status, not the earlier decrypt status. LAB has `vendor.ramoops.decryption.error=1`, `use_alt=0`, and empty pstore. No private key contents were read or copied. Therefore neither successful script exit nor an empty directory proves that the failed kernel produced no backtrace. Framebuffer console config does not guarantee a visible panic: display registration and panic timing must also permit output. `panic=0` does not by itself disable every independent hardware watchdog. ## Next diagnostic work 1. Preserve DEBUG as a named experiment with hashes/config/source snapshot. 2. Fix the lifetime defect in a subsequent isolated change. 3. Obtain panic trace or instrument milestones; distinguish kernel init, module load, init and zygote failures rather than infer timing from logo. 4. Use a matched kernel/vendor-module deployment and rollback. Never compare different system slots as though only boot changed. 5. Complete a modern SUSFS backport with the intended hook model, then verify real command responses, root denial, per-UID hiding and hardware behaviour. Boot success alone does not meet the requested result or feature gates.