DF-1193 — ciss CISS_BIG_MAP_BUS divide-by-zero (build/run scripts)

This finding is hardware-gated (HP Smart Array PCI controller). The guest has no such controller, so the bug cannot be triggered at runtime on this host. Source-level trace + a single-fix kernel build are the validation evidence.

Files

• VERDICT.md — detailed source-level analysis
• fix.diff — git-apply-able patch adding drives_per_scsi_bus==0 guard
• env.txt — guest environment snapshot
• fix_build.log — kernel-build output (cumulative batch, all 5 findings)

build.sh

#!/bin/sh
# No userspace PoC to build -- the bug is in the ciss driver attach path.
# Validate the fix.diff by building the kernel after applying it.
echo 'build.sh: no userspace PoC for DF-1193 (hardware-gated driver bug).'
echo 'To validate the fix, apply fix.diff and build a kernel:'
echo '  cd /usr/src && patch -p1 < fix.diff && make -j6 nativekernel KERNCONF=X86_64_GENERIC'

run.sh

#!/bin/sh
# Cannot be triggered on a guest without an HP Smart Array controller.
echo 'run.sh: DF-1193 is hardware-gated (HP Smart Array ciss).'
echo 'No HP controller is present on this guest (pciconf -l shows only i440FX/virtio).'
echo 'See VERDICT.md for the source-level confirmation.'

DF-1193 — ciss CISS_BIG_MAP_BUS divide-by-zero

Verdict

NOT REPRODUCED (source-confirmed; hardware-gated). The bug is real at the source level but the ciss driver attaches only to HP Smart Array controllers, which are absent from this QEMU/KVM guest. No runtime trigger possible; validated instead by line-level source trace + a single-fix kernel build that confirms the fix compiles cleanly.

Mechanism

CISS_BIG_MAP_BUS / CISS_BIG_MAP_TARGET at sys/dev/raid/ciss/cissreg.h:495-499 are macros of the form

#define CISS_BIG_MAP_BUS(sc, id)  \
    (((id) & 0x80) ? (((id) & ~0x80) / (sc)->ciss_id->drives_per_scsi_bus) : -1)

The divisor sc->ciss_id->drives_per_scsi_bus is a u_int8_t (cissreg.h:625) populated directly from the controller's BMIC ID_CTLR response in ciss_identify_adapter (ciss.c:1144-1230). There is no check that the field is non-zero. The macros are evaluated on every physical-hotplug notify (ciss_notify_hotplug, ciss.c:4026-4028) and during drive-status printing (ciss_print_ldrive, ciss.c:4223-4224, 4251-4252). A controller firmware reporting drives_per_scsi_bus=0 therefore triggers an int division by zero => kernel #DE trap.

Why not triggered on this guest

pciconf -l shows only i440FX/PIIX3/QEMU-std-VGA/virtio devices. The ciss driver's PCI attachment table targets HP/Compaq Smart Array controllers (vendor 0x0e11); none is present, so ciss_identify_adapter is never called and the divisor is never read. This is option (d) of the PoC-runner procedure: the sink is gated behind hardware absent from this guest.

Recommended fix (in fix.diff)

Reject the adapter in ciss_identify_adapter if the BMIC ID_CTLR response reports drives_per_scsi_bus == 0, mirroring the existing big_map_supported guard at ciss.c:1187-1191. Per the spec the field is the number of SCSI targets per bus and is always >= 1 on real HP hardware, so a 0 value is a malfunction signal and ENXIO is correct.

Build validation

All five findings in this batch (DF-1193/1194/1197/1200/1204) were validated together via a single cumulative nativekernel build on the with-src guest. NK_DONE rc=0; no errors. See fix_build.log.

Reproduce

./build.sh    # no-op (no trigger source for hardware-gated bug)
./run.sh      # no-op (no HP Smart Array controller on guest)

See fix.diff for the patch.