# DF-5523 — iicsmb_bread/bwrite trust the caller's count with no validation; the only /dev/smb caller passes an *uninitialized* stack byte that selects the on-wire transfer length (observed 0 and 255) and leaks back through `s.rcount`

## Files

  df5521_rig.c / df5521_poc.c / build.sh / load_chain.sh
      shared rig (see DF-5521); `proto` and `groom` and `race` modes
      provide the three observations below.
  run.baseline.log   uninit count = 0 (parent process) and = 255 (forked
                     child) driving the wire length; value disclosed in
                     s.rcount
  run.fixed.log      deterministic after fix (validation + seeding)
  fix.diff           two-part fix: bridge-side validation ([1,32],
                     mirroring ichsmb) + smb.c initializes bcount

## Reproduce

1. chain up (load_chain.sh), rdelay=0
2. `/root/df5521_poc proto`   → dmesg shows `READ req_len=0` (uninit byte)
3. `/root/df5521_poc race`-style child (or any different process context)
   → dmesg shows `READ req_len=255` — same slot, different junk
4. fixed modules → `proto` → deterministic `req_len=1`/`req_len=8`,
   out-of-range counts rejected with SMB_EINVAL.

## Why this is a real defect in the audited file

The smbus(4) block API bounds blocks at 32 bytes (SMBus spec; ichsmb
enforces `count < 1 || count > 32 → SMB_EINVAL` at both entry points,
ichsmb.c bwrite/bread).  `iicsmb_bread` (iicsmb.c:499) feeds `(int)*count`
straight into `iicbus_read()` — no bound, no minimum — and `iicsmb_bwrite`
(iicsmb.c:474) likewise.  The bridge is the only smbus driver in the tree
that performs zero validation on the caller-supplied count.  Combined with
the smb.c defect (`u_char bcount;` at smb.c:217 is never assigned before
`smbus_bread(bus, ..., &bcount, buf)` at smb.c:323), an uninitialized
kernel stack byte picks the transaction length — and is disclosed to the
ioctl caller via the copied-back `smbcmd.rcount` (`s->rcount = bcount`
side of the min() at smb.c:327-328).