# DF-4602 VERDICT — inconclusive

## What happened

During the feeder_chain.c pass-2 stress campaign (see README.md for the exact
recipe), the guest entered a minutes-long starvation state ~1-3 minutes after
the fuzz activity: sshd refused banner exchanges for minutes at a time
(intermittently recovering), the host qemu process burned 94-107% of a core
with oscillating guest load (0.96 -> 1.83 -> decay -> repeat), and the serial
console kept emitting `pcm0/pcm1: feeder_build_format(): can't add
feeder_format` / `feeder_build_rate(): can't set source rate` /
`feed_format_init(): failed ...` bursts as leftover fuzzer processes cycled
failing feeder-chain rebuilds. No panic, no watchdog, no deadlock detector
fired. The guest never fully died (TCP stack alive throughout) but was
administratively unusable for minutes.

## What I could not establish

1. **Root cause stack.** A QEMU-monitor `sendkey ctrl-alt-esc` broke into DDB
   (`Debugger("manual escape to debugger")`, all CPUs stopped — visible in
   `wedge-serial-full.log`), but DragonFly's console is `comconsole` and the
   rig's serial is file-backed, so DDB never saw my PS/2-injected keystrokes.
   No `ps`/`bta` -> spinner stack unknown. Candidates: console-lock
   contention from the print storm, CHN_LOCK/PCM_BUSY churn, or a
   driver-level softint livelock.
2. **Determinism.** After `vm.sh reset with-src`:
   * rerun1 (minimal: 1 fuzzer, /dev/dsp1, 45 s): NO wedge, cpu 10-20%.
   * rerun2 (full original recipe: 5 fuzzers + identical root churn):
     cpu 96-111% for ~2.5 min as expected, ONE transient ssh banner timeout,
     then healthy for ~4 more minutes; load 0.00 at the end.
3. **Real-hardware relevance.** The QEMU rig has NO host audio backend (ALSA
   init fails on the host), so the guest audio devices never raise transfer
   interrupts — exactly the dead-interrupt environment in which
   chn_sleep-timeout / CHN_F_DEAD / rebuild-storm interactions concentrate.
   This confounder cannot be excluded and plausibly does not exist on real
   hardware.

## Why filed (and at what confidence)

The in-file, indisputable component: **feeder_chain.c emits unconditional
`device_printf()` diagnostics on every failed rebuild and every format
ioctl rebuilds the whole chain**, so an unprivileged local user can sustain
an unbounded kernel console print rate through `SNDCTL_DSP_SETFMT` /
`SPEED` / `CHANNELS` storms (CWE-400 console-spam surface, lines :153, :164,
:227, :237, :305, :315, :361, :371, :429, :439, :472, :479, :509, :519 and
the destroy-rebuild loop at :575-579). Whether that surface alone explains
the observed whole-guest starvation is undetermined. Filed Low/speculative,
status inconclusive, impact dos (observed once).

## Fix validation

Not possible: no reproducible baseline. `fix.diff` gates all 14 diagnostics
behind `snd_verbose > 0` (compile-safe; `snd_verbose` is extern in
sound.h:314); it removes the spam surface and is the only defensible in-file
hardening, but is NOT claimed to fix the livelock.

## Guest state

Returned clean: `vm.sh reset with-src` after evidence capture.

## 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.