# DF-5575 — verdict narrative

## Finding
ppb_MS_loop() emits MS_DBRA(-1) whose branch lands on the DBRA itself — the loop body executes exactly once regardless of `iter`

## Bottom line (status: reproduced, impact: none)
Reproduced on the QEMU guest (DragonFly 6.5-DEVELOPMENT x86_64). The adapter-level branch contract (ppc.c:1447-1451 'mi += offset; mi++') resolves a branch target to mi+offset+1, corroborated by every working in-tree sequence (nibble_inbyte DBRA(-7) at index 6 targets index 0; ps2_inbyte DBRA(-4) at index 4 targets index 1; vpoio.c:195/210/226/239). ppb_MS_loop()'s generated sequence places the body CALL at index 2 and MS_DBRA(-1) at index 3 (ppb_msq.c:160-170): -1 from index 3 lands on index 3 — the DBRA itself — so the branch spins in place decrementing the accumulator (harness counter dbra_spins=4 for iter=5) while the body CALL is never re-executed: prolog=1 body=1 epilog=1 regardless of iter. The documented API contract ('execute a microseq loop', body iter times) is broken; the correct offset is -2. ppb_MS_loop() has zero in-tree callers (grep across sys/ finds only the definition/declaration), so this is latent dead-API logic damage: severity Info. Fix validated: MS_DBRA(-2) makes the same run print body=5 with prolog/epilog unchanged.

## Exploit chain
n/a

## Evidence
run.log ('DF-5575 iter=5 -> prolog=1 body=1 epilog=1 dbra_spins=4 ... BODY EXECUTED ONCE (off-by-one CONFIRMED)') on pristine production code; fix_run.log ('observed body=5 -> loop works') on the fix.diff-patched source; the adapter-contract derivation is documented in VERDICT.md

## Kernel references
- `sys/bus/ppbus/ppb_msq.c:160`
- `sys/bus/ppbus/ppb_msq.c:166`
- `sys/dev/misc/ppc/ppc.c:1447`
- `sys/dev/disk/vpo/vpoio.c:195`
- `sys/dev/disk/vpo/vpoio.c:210`

## Fix validation (fixed)
MS_DBRA(-1) -> MS_DBRA(-2): iter=5 now yields body=5 (prolog=1 epilog=1), matching the documented ppb_MS_loop() semantics; no other behavior changed.

`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; written fresh. Non-fatal counters via MS_C_CALL hooks + SUBRET, executed by the fake adapter interpreter replicating ppc semantics.

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.