# DF-3893 — mpssas_resetdev_complete dereferences a NULL task-management reply: XPT_RESET_DEV outstanding during a Diag Reset panics the kernel

File: `sys/dev/raid/mps/mps_sas.c` (pass 2). Twin of DF-3801 (mpr_sas.c).

## What

`mpssas_resetdev_complete` (`sys/dev/raid/mps/mps_sas.c:2791-2834`) is the
completion handler for XPT_RESET_DEV task-management commands. Unlike every
other TM completion handler in the file, it has **no `cm_reply == NULL`
guard** before dereferencing the reply:

```c
        resp = (MPI2_SCSI_TASK_MANAGE_REPLY *)tm->cm_reply;   /* :2799 */
        ccb = tm->cm_complete_data;

        if ((tm->cm_flags & MPS_CM_FLAGS_ERROR_MASK) != 0) {  /* :2807 */
                ... goto bailout;
        }

        kprintf("%s: IOCStatus = 0x%x ResponseCode = 0x%x\n",
            __func__, resp->IOCStatus, resp->ResponseCode);   /* :2819-2820 NULL deref */
```

`tm->cm_reply` is NULL whenever the command is completed by
`mpssas_complete_all_commands` (`sys/dev/raid/mps/mps_sas.c:1030-1073`),
which explicitly sets `cm->cm_reply = NULL` (line 1042) and then invokes
`cm->cm_complete(sc, cm)` (line 1053) for every outstanding command during
a diagnostic reset (`mpssas_handle_reinit` → `mpssas_complete_all_commands`,
mps_sas.c:1098; called from `mps_reinit`, mps.c:317).

Sibling handlers all guard this exact case:
- `mpssas_logical_unit_reset_complete` mps_sas.c:1160-1173
- `mpssas_target_reset_complete` mps_sas.c:1246-1259
- `mpssas_abort_complete` mps_sas.c:1378-1392
- `mpssas_remove_device` mps_sas.c:557-563, `mpssas_remove_complete`
  mps_sas.c:627-633, `mpssas_remove_volume` mps_sas.c:360-366

## Impact

Kernel NULL-pointer read (`resp->IOCStatus` at a small struct offset) →
panic. Trigger: any XPT_RESET_DEV in flight (issued by CAM error recovery
when a da(4) LUN keeps timing out, or by `camcontrol reset`) at the moment
error recovery escalates to a controller diagnostic reset
(`mps_reinit`, e.g. via `mpssas_tm_timeout` mps_sas.c:1131 or a NULL TM
reply escalation at mps_sas.c:1170/1256/1389). This is precisely the
recovery storm a failing disk produces.

## Build/run

`run.sh` records the hardware gate (no SAS2 HBA in the guest; driver
compiled in but SIM never attaches). Source-level certainty: total.

## Fix

Add the missing NULL guard, completing the CCB with CAM_SCSI_BUS_RESET and
freeing the TM (see fix.diff) — identical to the guard pattern of the three
sibling handlers and to the DF-3801 fix in mpr(4).