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:

        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).

DF-3893 — VERDICT

Status: not_reproduced (hardware-gated) — defect certain from source. Impact class (on real hardware): kernel panic via NULL deref (DoS).

Proof chain

1. sys/dev/raid/mps/mps_sas.c:2784-2787 — XPT_RESET_DEV is dispatched by mpssas_action (mps_sas.c:981-984) to mpssas_action_resetdev, which sends a TARGET_RESET TMF with tm->cm_complete = mpssas_resetdev_complete (mps_sas.c:2784).
2. mps_reinit (sys/dev/raid/mps/mps.c:285-363) runs on error-recovery escalation paths — mpssas_tm_timeout (mps_sas.c:1131), NULL-reply escalations in mpssas_logical_unit_reset_complete (mps_sas.c:1170), mpssas_target_reset_complete (mps_sas.c:1256), mpssas_abort_complete (mps_sas.c:1389), and the failed-target-reset escalation (mps_sas.c:1289).
3. mps_reinit → mpssas_handle_reinit (mps.c:317, mps_sas.c:1076) → mpssas_complete_all_commands (mps_sas.c:1098), which for every outstanding command sets cm->cm_reply = NULL (mps_sas.c:1042) and calls cm->cm_complete(sc, cm) (mps_sas.c:1053).
4. For an in-flight XPT_RESET_DEV, cm_complete is mpssas_resetdev_complete. Its ERROR_MASK branch (mps_sas.c:2807) is not taken (TM commands have no SGL, so CHAIN_FAILED cannot be set — the code's own comment at mps_sas.c:2802-2806 says so). It falls straight to kprintf(... resp->IOCStatus, resp->ResponseCode) at mps_sas.c:2819-2820 with resp == NULL → read at NULL+offset → kernel panic.
5. Contrast: all six other TM/IOU completion handlers in this file have the reply == NULL guard (mps_sas.c:360, 557, 627, 1160, 1246, 1378). mpssas_resetdev_complete is the lone omission — exactly the asymmetry that was DF-3801 in mpr_sas.c (fixed there by adding the guard).

Why not reproduced on this guest

No LSI SAS2 HBA exists in QEMU (env.txt, run.log): mps_attach never runs, no SIM registers with CAM, and XPT_RESET_DEV can never be routed to mpssas_action. Reproduction would need: real HBA + camcontrol reset (or a da LUN in deep error recovery) racing a controller diag reset; expected result: Fatal trap 12: page fault while in kernel mode reading near NULL in mpssas_resetdev_complete.

Exploitability

DoS/panic only (NULL-page read). No escalation path; not pursued beyond classification because the primitive is a fixed near-NULL read.

Fix validation

Not testable on this guest. fix.diff adds the same guard the three sibling handlers (and the mpr DF-3801 fix) use; behavior then matches mpssas_target_reset_complete's DIAGRESET cleanup path.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.