docs: overlayfs_setuid debug outcome — kernel confirmed vulnerable, raw /dev/fuse fragile, use libfuse

Confirmed CVE-2023-0386 vulnerable on jammy 5.15.0-25.25 empirically (upstream
xkaneiki libfuse PoC pops root). Isolated the raw /dev/fuse port's failures:
overlay refuses a userns-mounted FUSE lowerdir (ENOSYS) so FUSE must be mounted
in the init ns via the setuid fusermount3 helper; got the fd-passing handshake +
mount working, but the server EINVALs on read after FUSE_INIT (non-blocking fd,
needs poll) and the flaky raw server repeatedly wedged/rebooted the VM. Raw
protocol reimplementation is fragile and can destabilise the target -> use
libfuse (proven, matches pack2theroot conditional-lib precedent). Ledger updated.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y

docs/EXPLOITED.md

@@ -55,7 +55,7 @@ tamper check).
 | module | CVE | target tested | what's wrong |
 |---|---|---|---|
 | `ptrace_traceme` | CVE-2019-13272 | Ubuntu 18.04.2 / 4.15.0-50 | placeholder technique (now honest); needs the real cred-transfer PoC (polkit agent) — substantial port |
-| `overlayfs_setuid` | CVE-2023-0386 | Ubuntu 22.04.0 / 5.15.0-25 | genuinely vulnerable target. Investigated deeply (this session): the non-FUSE `chown` copy-up produces `upper/file` owned by **uid 1000, not root** here, so it doesn't escalate — the CVE needs the FUSE-reported-uid-0 lower. But **overlay refuses a userns-mounted FUSE lowerdir with `ENOSYS`** (plain overlay-in-userns works; FUSE-lower does not). A working port must mount FUSE in the **init ns** via the setuid `fusermount` helper (implement its fd-passing unix-socket protocol, or link libfuse), then overlay in the userns. A raw `/dev/fuse` server was written and reverted (hit the overlay-on-userns-FUSE `ENOSYS`). Substantial dedicated port. |
+| `overlayfs_setuid` | CVE-2023-0386 | Ubuntu 22.04.0 / 5.15.0-25.25 | **Kernel confirmed vulnerable empirically** — the upstream PoC (xkaneiki, libfuse) pops root here (`uid=0(root)`, root-owned witness). The working technique: mount a FUSE fs exporting `/file` (st_uid=0, mode 04777) in the **init ns** via the setuid `fusermount3` helper, then overlay-in-userns with that FUSE lowerdir + copy-up. My module's non-FUSE `chown` variant yields `upper/file` uid=1000 (no escalation); mounting FUSE **inside** the userns → overlay `ENOSYS`. Attempted a self-contained **raw `/dev/fuse`** port: got the `fusermount` fd-passing handshake (`SCM_RIGHTS`) + mount working, but the server hits `EINVAL` on `read()` after `FUSE_INIT` (non-blocking fd → needs `poll()`), and even with poll/buffer fixes the raw server serving was flaky and repeatedly **wedged/rebooted the VM** — i.e. the raw protocol reimplementation is fragile and can destabilise the target, which is *worse* for the corpus than a lib dependency. **Conclusion: use libfuse** (proven, robust; matches the `pack2theroot` conditional-lib precedent). Port is scoped and ready; needs a clean session to implement + verify. |
 | `sudoedit_editor` | CVE-2023-22809 | Ubuntu 22.04.0 / sudo 1.9.9 | vulnerable sudo version + sudoers `sudoedit` grant present; module returns `EXPLOIT_FAIL` — the `SUDO_EDITOR`/`--` arg-injection reaches sudoedit's writable-dir guard. Needs a target-file whose dir the injection can satisfy (e.g. `/etc/passwd`), and module debugging. Structural, tractable next. |
 | `sudo_samedit` | CVE-2021-3156 | Ubuntu 18.04.2 + 20.04.0 | honest `EXPLOIT_FAIL`; Baron Samedit is heap/libc-version-specific, needs a per-target tuned PoC. Hardest. |