AXP Magisk resurrection track: Speckit 009 port AXP/LOS22 to LOS23.

Ship Magisk like GOLDEN; KernelSU optional recycle only; parallel to sunfish-a16-rom standby.

docs/007-susfs-source-audit.md

@@ -0,0 +1,139 @@
+# 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 <Module.symvers> <module.ko>`.
+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.