DF-3897 — WarpDrive validation accepts NumPhysDisks == 0: divide-by-zero panic in mpssas_direct_drive_io

File: sys/dev/raid/mps/mps_sas.c (pass 2); the missing guard lives in sys/dev/raid/mps/mps_config.c, the fatal sinks are in this file.

What

WarpDrive (direct-drive) configuration is enabled by mps_wd_config_pages (sys/dev/raid/mps/mps_config.c), which validates the RAID volume page 0 as:

    if ((raid_vol_pg0->VolumeType != MPI2_RAID_VOL_TYPE_RAID0) ||
        (raid_vol_pg0->NumPhysDisks > 8)) {     /* mps_config.c:399-400 */
        ... "Direct Drive I/O will not be used" ... goto out;
    }
    ...
    sc->DD_num_phys_disks = raid_vol_pg0->NumPhysDisks;   /* mps_config.c:412 */
    ...
    sc->WD_valid_config = TRUE;                            /* mps_config.c:511 */

There is no NumPhysDisks == 0 rejection: a RAID0 page with zero physical disks passes the > 8 check, DD_num_phys_disks becomes 0, and WD_valid_config is set. Every subsequent READ/WRITE to the volume's DevHandle enters mpssas_direct_drive_io (mps_sas.c:1760-1762), which divides by it:

    stripe_unit = physLBA / sc->DD_num_phys_disks;   /* mps_sas.c:2190 (6-byte CDBs) */
    stripe_unit = physLBA / sc->DD_num_phys_disks;   /* mps_sas.c:2269 (10/16-byte, low LBA) */
    stripe_unit = physLBA / sc->DD_num_phys_disks;   /* mps_sas.c:2347 (16-byte, high LBA) */

An integer division by zero in kernel text on x86_64 raises #DE → panic: integer divide by zero (or fatal trap) on the first qualifying I/O — an unprivileged process merely has to read() or write() a file on the wed volume-shaped device.

Contrast: the same function does reject stripe-size 0 and block-size 0 explicitally (mps_config.c:428-433, 447-452) — the disk-count zero case was simply missed. (Note stripe_size==0 → the virtLBA & (DD_stripe_size - 1) masks at mps_sas.c:2185/2263 also degrade, but the div-by-zero fires first in the zero-disk case.)

Threat model

NumPhysDisks comes from the controller's own config-page DMA (firmware / NVRAM-backed volume table), not from disk-supplied data — so this is a malicious-or-corrupt-firmware / mis-flashed-WarpDrive scenario, or a legitimate LSI firmware bug class (0-disk RAID0 pages have been observed during volume teardown races). Hardware- and firmware-gated; hence Low / speculative, but the sink is a guaranteed kernel panic.

Build/run

run.sh records the hardware gate.

Fix

Reject NumPhysDisks == 0 in the WarpDrive validation (mps_config.c:399-400). See fix.diff.

DF-3897 — VERDICT

Status: not_reproduced (hardware/firmware-gated) — sink certain from source, trigger speculative. Impact class: divide-by-zero kernel panic (DoS), Low.

Proof chain

1. sys/dev/raid/mps/mps_config.c:399-405 — the only NumPhysDisks check is > 8; == 0 passes. (VolumeType must be RAID0, which does not imply disk-count ≥ 1 to the parser.)
2. sys/dev/raid/mps/mps_config.c:412 — sc->DD_num_phys_disks = raid_vol_pg0->NumPhysDisks; (uint8_t, mpsvar.h:435); validation continues; sc->WD_valid_config = TRUE at mps_config.c:511 (the function bails to out: before this on every checked anomaly — stripe 0 at 428-433, block 0 at 447-452, multiple volumes at 481-486, bad PD pages at 495-507 — but not for count 0).
3. sys/dev/raid/mps/mps_sas.c:1760-1762 — every XPT_SCSI_IO on the adapter then calls mpssas_direct_drive_io(sassc, cm, ccb).
4. sys/dev/raid/mps/mps_sas.c:2157-2191, 2222-2277, 2306-2391 — for READ/WRITE 6/10/16 to sc->DD_dev_handle, once the LBA/stripe checks pass: stripe_unit = physLBA / sc->DD_num_phys_disks; at 2190, 2269,
5. With DD_num_phys_disks == 0 → #DE → kernel panic on first qualifying I/O by any unprivileged user of the device.
6. Column note: column = physLBA % DD_num_phys_disks (2191, 2271, 2349) indexes DD_column_map[column] — with the count check fixed to ≥ 1 the modulo bounds column < count ≤ 8 = MPS_MAX_DISKS_IN_VOL, so that side is safe once this finding is fixed.

Why not reproduced

Needs a real LSI WarpDrive/SAS2 HBA reporting a 0-disk RAID0 volume page; the QEMU guest has none (env.txt/run.log). Speculative trigger, certain sink.

Fix validation

Not testable here; fix.diff adds the == 0 rejection beside the existing > 8 check — one line, same style as the stripe/block zero guards.

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.