# DF-1184 — arcmsr_Read_iop_rqbuffer_data_D: 128-byte kmalloc overflowed by firmware data_len

## Finding
`arcmsr_Read_iop_rqbuffer_data_D()` (`arcmsr.c:1437-1477`) for Type B/C/D
adapters:
- `:1446` reads `iop_len = (u_int32_t)prbuffer->data_len` — a 32-bit length
  field whose source is MMIO/DMA from the Areca IOP firmware.
- `:1449` allocates `buf1 = kmalloc(128, M_DEVBUF, ...)` — only **128** bytes.
- `:1454-1458` copies `iop_len` bytes (4 at a time) into `buf1`.

The caller `arcmsr_iop2drv_data_wrote_handle()` (`:1511-1526`) only bounds
`data_len` against `ARCMSR_MAX_QBUFFER-1 = 4095` (`:1519-1521`), never against
128. So a malicious/compromised Areca controller (or PCI-passthrough device)
supplying `data_len` in (128, 4095] overflows the 128-byte heap object by up
to ~3967 bytes. `struct QBUFFER.data` is itself only 124 bytes
(`arcmsr.h:1059-1062`), so even a legitimate-looking `data_len` ≤ 4095 is
unbounded relative to the kmalloc.

## Why harness
`arcmsr` IS in `X86_64_GENERIC` but the driver only attaches to Areca RAID
PCI controllers (vendor `0x17d3`); none are present on the QEMU guest, so the
ISR path that calls this function is never reached. Harness replays the
function with crafted `data_len` against the real 128-byte allocation.

## Build & run
```
./build.sh && ./run.sh
```

## Expected
Harness shows the heap buffer overrunning at `data_len > 128` (up to 4095) and
the resulting OOB write into adjacent slab memory.