DF-5523 baseline (stock): caller-supplied *count drives the transfer,
/dev/smb passes an UNINITIALIZED stack byte, and its value leaks back
=====================================================================
#/root/df5521_poc proto   (parent process, fresh stack state)
poc: SMB_BREAD#0 -> 0 asked rcount=16 got rcount=0 rbuf=
(6/6 identical)
#dmesg:
df5521-wire: READ req_len=0  <== bridge *count
df5521-wire: READ gave 0 bytes: ...
=> the transfer length came from smb.c's `u_char bcount` (declared at
   smb.c:217, NEVER assigned before smbus_bread at smb.c:323).  In this
   process context the uninitialized slot reads 0: a zero-length
   "successful" block read, and the byte's value is handed back to
   userland in s.rcount (min(16, 0) = 0).

#uninitialized variance (different process context -- forked child in
#`race` mode, same binary, same ioctl):
df5521-wire: READ req_len=255  <== bridge *count
df5521-wire: READ gave 255 bytes: 08 a0 a1 a2 ...
=> the SAME uninitialized slot reads 255 in another process: the bridge
   transferred 255 bytes on the wire -- kernel-stack junk picked the
   transaction length.  0 in one process, 255 in another: the value is
   environment-dependent uninitialized memory, not program state.

(groom mode: pre-filling smbioctl's 1024-byte stack buf with 0x99 via a
prior BWRITE did not reach the bcount slot in this build -- the compiler
placed it outside the copyin region; the 0-vs-255 process-context
variance is the demonstration.)