# DF-3815 — mpr_resize_queues(): division by zero on IOCMaxChainSegmentSize == 1 (device-controlled panic)

## What

`mpr_resize_queues()` (sys/dev/raid/mpr/mpr.c:364-453):

```c
if (sc->facts->MsgVersion >= MPI2_VERSION_02_05) {           /* mpr.c:397 */
        chain_seg_size = htole16(sc->facts->IOCMaxChainSegmentSize);
        if (chain_seg_size == 0)                              /* mpr.c:399 */
                chain_seg_size = MPR_DEFAULT_CHAIN_SEG_SIZE;  /* = 8 */
        sc->chain_frame_size = chain_seg_size *
            MPR_MAX_CHAIN_ELEMENT_SIZE;                       /* *16 */
} ...
sges_per_frame = sc->chain_frame_size/sizeof(MPI2_IEEE_SGE_SIMPLE64)-1;  /* mpr.c:416 */
...
sc->num_chains = (maxio / PAGE_SIZE + sges_per_frame - 2) /
    sges_per_frame * reqcr;                                   /* mpr.c:431-432 */
```

`sges_per_frame == IOCMaxChainSegmentSize - 1`. Only `== 0` is special-cased;
a firmware reporting `IOCMaxChainSegmentSize == 1` yields
`sges_per_frame == 0` and the division at mpr.c:431 **divides by zero** →
integer-divide trap → kernel panic. (SAS3 firmware always reports ≥ 2.05
message version, so the guard is always taken.)

## Threat

The value comes straight from the controller's IOC Facts reply (doorbell
read in `mpr_request_sync()`, stored unvalidated into `sc->facts`). A
malicious/broken PCIe device (or corrupted DMA/doorbell) is fully trusted
here — the same device-trust class as the already-filed DF-1228 (SMID) but a
distinct sink. Impact: unauthenticated kernel panic at attach or at any
reallocating reinit → local DoS by inserted hardware. No privilege boundary
is crossed; severity Low per the "requires specific hardware" rubric row.

## Not runnable here

Guest has no SAS3 controller (probe.log identical to DF-3814's); the panic
can only be proven on real (or emulated malicious) hardware.

## Fix

Clamp `chain_seg_size < 2` to the default (see fix.diff).

## Env

- DragonFly dfbsd 6.5-DEVELOPMENT #0 (X86_64_GENERIC), x86_64