# DF-2863 VERDICT

**Status: reproduced (KLD replica with the kernel's own ksscanf on the
live stock kernel #0, AND on the real boot path with a crafted
`vfs.root.mountfrom`; fix validated on rebuilt kernel #1).**
**Impact: dos / root-selection integrity — the `;`-separated candidate
fallback list is silently broken for every candidate except the last;
a valid earlier candidate can never mount, so an operator fallback
configuration can panic at boot (`Root mount failed, startup aborted.`,
vfs_conf.c:208) or mount an unintended (last) device as root. Severity
Low: boot-time, loader/console-gated.**

## Root cause (path:line)

1. `sys/kern/vfs_conf.c:422-423` — the loop computes `ep` = end of the
   current `;`-delimited candidate.
2. `sys/kern/vfs_conf.c:427` — `strncpy(mf, cp, MFSNAMELEN+MNAMELEN)`
   copies from `cp` to the end of the *whole string* (or 96 bytes),
   ignoring `ep`.
3. `sys/kern/vfs_conf.c:430-431` — pattern `%16[a-z0-9]:%80s`;
   `%80s` (subr_scanf.c:359-386 CT_STRING) terminates only on
   whitespace, never on `;` — so all remaining candidates fold into
   `devname`.
4. `sys/kern/vfs_conf.c:435-436,447` — the contaminated `devname` goes
   to `vfs_rootmountalloc()`/`setrootbyname()` → `kgetdiskbyname()`
   → device lookup fails (`no disk named 'da0s1a;ufs:'` — observed
   verbatim at boot, bootpath-baseline.log).

## Proof

- Replica A1 (run.log): `devname='da0s1a;ufs:da1s1a'` for candidate 1
  of `ufs:da0s1a;ufs:da1s1a` — kernel's own parser, verbatim parse copy.
- Boot path (bootpath-baseline.log): stock kernel #0 with
  `vfs.root.mountfrom="ufs:da0s1a;ufs:<92 spaces>E;hammer2:vbd0s1d"`:
  `no disk named 'da0s1a;ufs:'` printed at boot; candidate 1 (and 2)
  fail; only the last candidate mounts. This shows the exact intended
  primary device `da0s1a` was never even looked up.
- Fixed (bootpath-patched.log): kernel #1 with the shared fix
  (copy bounded at `ep`): `no disk named 'da0s1a'` — candidate parses
  exactly as configured; machine boots via the last candidate as
  intended.

## Exploit chain

None (boot-time configuration handling). The realistic worst cases are
(a) boot panic when the last candidate is absent though an earlier
candidate is valid, and (b) silent selection of the wrong root device
when the primary is the non-last entry — an integrity property of root
selection, not an unprivileged runtime attack.

## Fix validation

Shared `fix.diff` with DF-2862 (same hunk): validated on kernel #1 —
contamination gone at boot with identical input. Guest restored with
`vm.sh reset with-src`.