# DF-5627 — ppb_get_epp_protocol(): BUS_READ_IVAR failure ignored, uninitialized `protocol` returned (stale kernel stack)

File: `sys/bus/ppbus/ppb_base.c:100-108`

## Build (inside the DragonFly guest)

```
sh build.sh     # compiles VERBATIM /usr/src/sys/bus/ppbus/ppb_base.c into ppbbasehx.ko
```

## Run (inside the guest)

```
sh run.sh
```

## Expected (decisive lines, see run.log)

```
PPBHX: DF-5627 stack dirtied 0x41 -> protocol=0x41414141
PPBHX: DF-5627 stack dirtied 0x42 -> protocol=0x42424242
PPBHX: DF-5627 stack dirtied 0x43 -> protocol=0x43434343
```

`ppb_get_epp_protocol()` declares `uintptr_t protocol;` **uninitialized**,
discards the `BUS_READ_IVAR(...)` return value (ppb_base.c:105), and
returns `protocol`.  Any parent that fails the ivar read without writing
`*result` — the generic behavior (e.g. `ppc_read_ivar()`'s own default
branch at ppc.c:2060, or any non-ppc controller, which by construction has
no PPC ivars) — makes the function return stale kernel-stack bytes.  The
harness dirties the stack with 0x41/0x42/0x43 patterns immediately before
each production-code call; the return value reproduces those patterns
byte-for-byte.

In-tree today the only ppbus parent is `ppc`, which always writes
`PCP_IVAR_EPP_PROTO` (ppc.c:2053-2055), so the bug is latent in-tree; its
in-tree consumer is `mode2xfer()` (ppb_msq.c:85) whose `default:` branch
`panic`s on any protocol other than {0,1} (the DF-5576 sink) — so garbage
either panics the kernel or silently selects the wrong EPP submicroseq.

## Fix validation

```
fix_run.log (ppb_base.c patched with an initializer, rebuilt, re-run):
PPBHX: DF-5627 stack dirtied 0x41 -> protocol=0x00000000
PPBHX: DF-5627 stack dirtied 0x42 -> protocol=0x00000000
PPBHX: DF-5627 stack dirtied 0x43 -> protocol=0x00000000
```

Guest `/usr/src` was restored to pristine afterwards (cmp-verified).

## Harness note

One shared KLD harness demonstrates DF-5625/5626/5627/5628; this pack's
lines are the `DF-5627` ones.