# DF-5573 — verdict narrative

## Finding
ppb_MS_init_msq(): instruction index `ins` is never bounds-checked — controlled OOB kernel write of up to ~8 KB from the microsequence array

## Bottom line (status: reproduced, impact: none)
Reproduced on the QEMU guest (DragonFly 6.5-DEVELOPMENT x86_64) via the KLD-harness-with-production-code evidence class: the unmodified /usr/src/sys/bus/ppbus/ppb_msq.c (sha256 223e7f91..., identical to the repo sys/ copy) was compiled with -Werror into msqhx.ko and driven against a fake ppbus controller implementing the ppc_exec_microseq() contract. ppb_MS_init_msq() extracts the instruction position with MS_INS(param) (8 bits wide, ppb_msq.h:38) but validates only the argument index (arg >= PPB_MS_MAXARGS panic at ppb_msq.c:206-208); `ins` is used directly as msq[ins].arg[arg] at ppb_msq.c:218/222/226/230 with no bound. Harness case 0 proves the primitive on a private kmalloc'd 256-instruction buffer: MS_PARAM(60,0,MS_TYP_INT) writes 0x41424344 at +1792 bytes past a 4-instruction caller array and MS_PARAM(200,2,MS_TYP_PTR) writes a pointer value at +6416 bytes (max reachable: ins=255, arg=2, MS_TYP_PTR/FUN -> +8184 bytes, 8-byte value). A buggy or third-party KLD driver that computes a descriptor from runtime data (instead of the compile-time MS_PARAM constants all in-tree callers use) gets silent kernel memory corruption rather than the panic the half-sibling `arg` check provides. Impact ceiling: with no unprivileged input path into descriptors (ppi's user-reachable microseq code is #if 0'd, ppi.c:419-442; all other callers pass static descriptors) this is a kernel-API hardening defect (driver-misuse -> corruption), not a direct privilege boundary; severity Low, bucket memcorrupt-class primitive. Fix validated: ins >= PPB_MS_MAXLEN(64) now panics fail-fast ('instruction out of range (200)', production backtrace ppb_MS_init_msq+0x1f9 in fix_run.log) and the in-bounds regression (ins=2) still initializes correctly. Residual: the function cannot know the caller's actual array length, so ins<64 remains trusting; a complete fix would pass the array length (KPI change).

## Exploit chain
n/a (kernel-internal API; no unprivileged descriptor input exists in-tree — primitive characterized on a private buffer instead)

## Evidence
run.log lines 'OOB ins=60 ... CONTROLLED WRITE LANDED' / 'OOB ins=200 ... CONTROLLED WRITE LANDED' (baseline, pristine production code); fix_run.log (in-bounds ok + 'panic: ppb_MS_init_msq: instruction out of range (200)' with production backtrace); build.log ('-c /usr/src/sys/bus/ppbus/ppb_msq.c' with -Werror, sha256 223e7f91...); VERDICT.md

## Kernel references
- `sys/bus/ppbus/ppb_msq.c:201`
- `sys/bus/ppbus/ppb_msq.c:206`
- `sys/bus/ppbus/ppb_msq.c:218`
- `sys/bus/ppbus/ppb_msq.c:222`
- `sys/bus/ppbus/ppb_msq.c:226`
- `sys/bus/ppbus/ppb_msq.c:230`
- `sys/bus/ppbus/ppb_msq.h:38`
- `sys/bus/ppbus/ppbconf.h:135`

## Fix validation (fixed)
Applied 'ins >= PPB_MS_MAXLEN -> fail-fast panic' to the guest's /usr/src copy and rebuilt the harness: the ins=200 OOB write is now blocked by 'panic: ppb_MS_init_msq: instruction out of range (200)' (production frame ppb_MS_init_msq+0x1f9) and the in-bounds ins=2 initialization still works. Residual documented: ins<64 cannot be checked against the caller's real array length without a KPI change.

`fix.diff` (sha256 8e3dfc90e6049ce1704c3cef833cba0904b6404f11360bdd299e37980e9327bb) carries all five ppb_msq.c fixes for this pass;
the hunks relevant to this finding are marked with its DF id in the comments.
Fix validation followed the family standard (cf. DF-5418): the fixed sources
were installed into the guest's `/usr/src/sys/bus/ppbus/`, the harness was
rebuilt (recompiling the production file), and the exact same case was
re-run — baseline vs patched outputs are in `run.log` / `fix_run.log`
(+ `panic*.txt`). The repo's `sys/` tree was never modified; the guest was
`vm.sh reset with-src` afterwards (sources restored+verified by snapshot).

## PoC changes vs seed
No seed PoC existed; harness written fresh. Iterations: (1) load-time kenv tunable replaced by sysctl hw.msqhx_case after the first module could not be unloaded (drivers initially lacked detach methods); (2) diagnostic reads of the fix-added ppb_in_xfer field removed so the same harness compiles against pristine and patched headers. Production ppb_msq.c compiled clean on first attempt.

Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul  2 06:02:54 UTC 2026     root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC  x86_64
Harness sha256: 4b728315b40157934f62c99e847f386b30202eef77083dc1a5c065b7b0448ded

## Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest `make -j6 nativekernel KERNCONF=X86_64_GENERIC` completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.