# DF-5547 — fwmem_read_block() quadlet-roundup receive length exceeds the destination buffer

* File: `sys/bus/firewire/fwmem.c`
* Bug: `fwmem.c:197` — `fwmem_xfer_req(fwdev, sc, spd, 0, roundup2(len, 4), hand)`
  sets `xfer->recv.pay_len = roundup2(len, 4)` while `xfer->recv.payload`
  (`fwmem.c:209`, = `bp->b_data` from `fwmem_strategy` `fwmem.c:365-368`) is
  only `len` bytes (`iolen = MIN(bp->b_bcount, MAXLEN)`, odd `b_bcount`).
* Sink: `firewire.c:1707-1722 fw_rcv_copy()` caps the copy at
  `recv.pay_len`, not at the buffer length → responder payload bytes
  `[len .. roundup2(len,4))` are written past the buffer end.

## Build (guest, root)

```
sh build.sh        # compiles UNMODIFIED production firewire.c + fwmem.c
                   # into df5547.ko (globals -D-renamed)
```

## Run

```
sh run.sh          # kldload + sysctl kern.df5547_test=1
```

## Expected

Console shows, for the groomed cross-chunk layout (`b_data = C+3`,
`b_bcount = 29`, guard chunk `N = C+32`):

```
df5547: bcount=29 pay_len=32 ... bytes past buffer: 41 42 43 AA -> OOB WRITE
df5547: N[0..3] now: 41 42 43 AA (was AA AA AA AA)
```

and `sysctl kern.df5547_status` reports `DF-5547 REPRODUCED (cross-chunk …)`:
up to 3 responder-controlled bytes written past the end of the caller's
buffer — in the groomed layout, into the adjacent heap chunk.  Negative
controls (b_bcount multiple of 4) show no change.

Impact ceiling honestly noted: on current DFly `physio()`
(`sys/kern/kern_physio.c`) user reads use a bounce buffer, so for plain
`read(fd, buf, odd)` the extra bytes land in bounce-buffer slack; any
kernel-side bio issuer / UIO_SYSSPACE read gets the full out-of-bounds
write.  The RPC contract violation (`pay_len` > buffer) is unconditional.