# DF-5419 — VERDICT

**Status: reproduced** (KLD-harness-with-production-code; guest
DragonFly 6.5-DEVELOPMENT x86_64; same `ppbharness.ko` rig as DF-5418,
test T4).

## Root cause (static)

`ppb_1284_read_id()` (`ppb_1284.c:588-606`) never initializes `*read`.
Both early error returns (`ppb_1284.c:600-601` and `605-606`) return
the negotiation error without writing the out-parameter, and the
function only reaches `spp_1284_read()` (which sets it) on the success
path. The sibling reader `spp_1284_read()` demonstrates the correct
pattern — `*read = len = 0;` at `ppb_1284.c:526` — so the omission in
`ppb_1284_read_id()` is clearly an oversight, not a contract.

Every peer-controlled negotiation failure (device not IEEE 1284
compliant → `PPB_NOT_IEEE1284`, timeout, mode unsupported) leaves the
caller's `int` untouched.

## Observed (run.log, baseline)

```
PPBHX: DF-5419 T4 read_id-negotiate-fail: ret=19 read=0x5a5a5a5a state=0 error=2
```

The `0x5A5A5A5A` poison sentinel survived the call through the
production `ppb_1284_read_id()` — `*read` was never written. `error=2`
(`PPB_NOT_IEEE1284`) confirms the production error path (Event 2
timeout in `ppb_1284_negotiate`) was taken.

## Fix validation (fix_run.log, fixB phase / ppb_1284.fixB.c)

One-line fix — `*read = 0;` before `bzero()`:

```
PPBHX: DF-5419 T4 read_id-negotiate-fail: ret=19 read=0x00000000 state=0 error=2
```

Sentinal replaced by 0 on the same error path → **fixed**. Rebuilt with
`-Werror`, pristine source restored + `cmp`-verified.

## Impact ceiling

None in-tree: the only caller, `ppb_pnp_detect()` (`ppbconf.c:224`),
checks the return code before ever looking at `len`. The defect is a
latent-contract hazard — any present or future caller that reads `*read`
after an error return consumes an uninitialized kernel stack value
(info-leak-grade primitive of 4 bytes of adjacent stack). Filed as
**Info** (hardening), confidence **certain** (static + demonstrated
through production code).

Note: the related "missing NUL-termination of the PnP string" defect
that lets `ppb_pnp_detect()` walk past the 256-byte device-ID buffer is
**already filed** as DF-2328 (ppbconf.c, pass 1) and is intentionally
not re-reported here.

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