# DF-4377 VERDICT — not_reproduced (hardware-gated), defect certain from source

## Reproduced?

**No — the target hardware does not exist on the audit guest.**
`chk_bktr.c` compiled and ran on the guest (`BUILD_OK_4377`, run.log); the open of
`/dev/bktr0` fails with ENOENT because the QEMU guest has no Brooktree PCI device and
the bktr driver is not attached (`pciconf -l | grep -c brooktree` → 0, no
`/dev/bktr*` `/dev/tuner*` `/dev/vbi*` nodes). The vulnerable code only executes
inside `probeCard()` during device attach (bktr_core.c:505) or on the first open
after a `hw.bt848.card`/`hw.bt848.tuner` sysctl change (bktr_os.c:463/473) — i.e.
only on a machine with a real Bt848/Bt878 capture card.

## Why the defect is certain anyway (path:line)

1. `sys/dev/video/bktr/bktr_card.c:605` — `u_char eeprom[256];` kernel-stack array,
   **not initialized**.
2. `bktr_card.c:420-448` — `readEEProm()` writes `data[x]` only for bytes whose i2c
   read succeeded; on the first `i2cRead() == -1` it returns `-1` with the buffer
   partially (or entirely) uninitialized. It can also fail at the bounds check
   (:433-434) or the address-set write (:437) before touching the buffer at all —
   in those cases *nothing* is initialized.
3. Every call site in `probeCard()` ignores the return value:
   - :667 `readEEProm(bktr, 0, 256, (u_char *)&eeprom);` (Bt878/879 path)
   - :794 `readEEProm(bktr, 0, 128, ...)` (Bt848 Hauppauge/Osprey path)
   - :1001 `readEEProm(bktr, 0, 128, ...)` (Hauppauge tuner re-parse)
   - :1129 `readEEProm(bktr, 0, 128, ...)` (AVerMedia re-parse)
4. Uninitialized bytes are then **consumed and printed**:
   - :668-674 `subsystem_id`/`subsystem_vendor_id` from `eeprom[252..255]`;
   - :676-678 bootverbose print of both;
   - :757-758 **unconditional** "Warning - card vendor 0x%04x (model 0x%04x)
     unknown" for any garbage vendor id;
   - :797/:805 `eeprom[0..3]` compared, :812-815 **unconditional** print of the
     four bytes when unrecognized;
   - :1004-1019 `block_1[1..15]` of the (possibly never-written) buffer drive the
     Hauppauge block walk — with DF-1569's missing bounds this turns uninitialized
     stack into wild offsets (that specific OOB remains DF-1569's scope; the
     *uninitialized source* is this finding).

Trigger condition on hardware: `locate_eeprom_address()` (:525-530) must see an ACK
at 0xa0/0xac/0xae while the subsequent sequential read NAKs — i.e. exactly the
"EEPROM present but read fails" case the helper models. Then :667 returns early,
and :668-674/:676/:757 print uninitialized stack. On the :794 path the probe read at
:788 (`i2cRead(PFC8582_RADDR)`) succeeded, so a mid-`readEEProm` failure leaves
`eeprom[0..3]` uninitialized and :814-815 prints them.

## Impact assessment

- Kernel-stack disclosure: 4-16 uninitialized bytes per probe printed to
  console/dmesg (readable by unprivileged users unless dmesg is restricted). Same
  class and ceiling as DF-2092 (cxm_eeprom.c), which was triaged Low.
- Secondary: nondeterministic card misidentification → wrong tuner/audio config
  (correctness, not a memory-safety primitive).
- No userland trigger exists for the uninit path itself: the BT848_REEPROM ioctl
  copies the argument through a zeroed kernel buffer (`mapped_ioctl`,
  sys/kern/sys_generic.c:674-697, bzero's IOC_OUT), so the ioctl-driven variants of
  readEEProm cannot disclose stack; only the probe-time kprintfs do.

## Exploit chain

None — information disclosure of a few stack bytes; not a corruption primitive.

## Fix validation

`fix.diff` (zero-init `eeprom[]` in probeCard) is authored against the read-only
`sys/` tree and **not applied**; fix validation is `not_testable` on this guest
(no hardware to observe the disclosure before/after). The change is trivially
reviewable: it makes a failed read produce vendor id 0x0000 (prints as
"vendor 0x0000 unknown") instead of stack garbage.

## Guest evidence

- `run.log`: uname, BUILD_OK, `/dev/bktr0 not present`, EXIT=2, no bktr/tuner/vbi
  nodes, `pciconf -l | grep -ci brooktree` = 0.
- `env.txt`: guest identity + device-absence summary.

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