# VERDICT -- DF-2016 (Low)

**Verdict:** REPRODUCED (source-only)

**Impact:** NULL-deref panic (local DoS) / 1-byte heap OOB; HW-gated (needs mfi(4) + passthrough), source-confirmed

**Confidence:** speculative

## Mechanism (source-traced)

mfip_done (mfi_cam.c:329-345) on MFI_STAT_OK reads the CDB opcode (:335-338) and, if INQUIRY (0x12), unconditionally executes device = csio->data_ptr[0] & 0x1f (mfi_cam.c:340) and a conditional write at :342-343. There is NO guard that data_ptr != NULL, dxfer_len > 0, or that the transfer carried an INQUIRY payload. mfip_start sets cm_data=NULL, cm_len=0 for CAM_DIR_NONE (mfi_cam.c:306-311) but never clears csio->data_ptr, so a CAM_DIR_NONE INQUIRY with NULL data_ptr that the firmware returns MFI_STAT_OK for dereferences NULL => panic.

## Why not runtime-reproduced

The guest (DragonFlyBSD 6.5-DEVELOPMENT #0 master DEV, KVM) has NO matching
hardware: pciconf shows no mfi/tws/iir RAID controller and no amdgpu/DRM GPU;
the driver therefore cannot attach and the vulnerable path is not runtime-
triggerable here. The defect was **confirmed at the source level** by tracing
the cited `path:line` against `sys/`, and the proposed fix was applied and the
affected module (`mfi / mfip`) built clean with `-Werror` (see fix_build.log).

## Fix

mfi_cam.c:339: tighten the INQUIRY condition to also require csio->data_ptr != NULL && csio->dxfer_len > 0 before the deref/write.

The standalone, git-apply-able diff is `fix.diff`.