DF-1190 — ciss_init_logical out-of-range bus/target index -> OOB write

File: sys/dev/raid/ciss/ciss.c:1391-1396 Class: memory corruption (hardware/firmware-attacker; malicious CISS PCI device or malicious VBIOS at driver attach). No local-unprivileged syscall trigger on the audit guest (no HP Smart Array / no AMD GPU present).

Reproduce

./build.sh && ./run.sh

What the harness does

harness.c is a faithful userspace replica of the kernel parsing routine cited above, fed crafted controller/VBIOS data that the real malicious device would supply. It demonstrates the out-of-bounds access / overflow / underflow using the real kernel macros and struct sizes, with a canary or computed-index check to make the OOB observable without needing the hardware.

Expected output

A [BUG REPRODUCED] (or UNDERFLOW for DF-1199) marker plus the computed out-of-range index / overflow byte count / underflowed loop count. See run.log for the captured decisive run.

Fix

See fix.diff (git-apply-able) and VERDICT.md. The fix was validated to compile (module rebuilt with -Werror) — see fix_build.log. No live-kernel trigger exists on the guest, so the fix is validated at the applies + compiles + closes-the-code-path level.

Artifacts

VERDICT.md (full narrative), harness.c, build.sh, run.sh, run.log, env.txt, fix.diff, fix_build.log, manifest.json.

DF-1190 — ciss_init_logical out-of-range bus/target index (OOB write)

Verdict

REPRODUCED (harness) — real bug confirmed by source trace + userspace replica. Impact class: kernel heap OOB write / OOB pointer store. No local-unprivileged trigger on the audit guest (no HP Smart Array controller); trigger requires a malicious/emulated CISS PCI device at driver attach. uid=0 escalation chain is N/A — this is a hardware/firmware-attacker primitive (driver-probe time), not a syscall-driven local-privesc path.

Mechanism (confirmed path:line)

ciss_init_logical() (sys/dev/raid/ciss/ciss.c) walks the controller's REPORT_LOGICAL_LUNS reply and decodes each LUN's 8-bit bus and target from controller-supplied data:

• sys/dev/raid/ciss/ciss.c:1391 — bus = CISS_LUN_TO_BUS(cll->lun[i].logical.lun);
• sys/dev/raid/ciss/ciss.c:1392 — target = CISS_LUN_TO_TARGET(cll->lun[i].logical.lun);
• sys/dev/raid/ciss/ciss.c:1393 — ld = &sc->ciss_logical[bus][target];

The index macros (sys/dev/raid/ciss/cissreg.h:509-510) yield 0..255 for each of bus and target, but the arrays are far smaller: - ciss_logical is ciss_max_logical_bus rows × CISS_MAX_LOGICAL(15) cols (cissvar.h:49, allocated at ciss.c:1372-1383), - ciss_controllers is ciss_max_logical_bus entries (ciss.c:1484-1486).

There is no bounds check between decoding bus/target and indexing. With bus >= ciss_max_logical_bus or target >= 15: 1. sc->ciss_logical[bus] reads an out-of-bounds pointer (row pointer past the array), 2. ld->cl_controller = &sc->ciss_controllers[bus] writes an OOB kernel pointer into the corrupted ld (ciss.c:1396), 3. ciss_identify_logical(sc, ld) then kmallocs into ld->cl_ldrive / ld->cl_lstatus (ciss.c:1397) — controlled heap writes through the OOB-corrupted ld.

The earlier sanity check at ciss.c:1357 only bounds ndrives (the count) to CISS_MAX_LOGICAL; it does not validate the per-LUN bus/target encodings.

Harness proof (run.log)

harness.c replicates the exact loop with the real CISS_LUN_TO_BUS / CISS_LUN_TO_TARGET macros and a ciss_max_logical_bus=1 layout, feeding a forged LUN with bus=200/target=250 and another with bus=0/target=40:

[!] OOB index drive=0 bus=200 (max 1) target=250 (max 15) -> writes ciss_logical[200][250] + ciss_controllers+200
[!] OOB index drive=1 bus=0 (max 1) target=40 (max 15) -> writes ciss_logical[0][40] + ciss_controllers+0
[BUG REPRODUCED] 2 out-of-range index accesses observed

Why not a live-kernel trigger / no uid0 chain

ciss is a module (/boot/kernel/ciss.ko, device ciss in X86_64_GENERIC:115) that attaches only to HP Smart Array PCI devices (ciss_pci_attach). The audit QEMU guest has no CISS controller, so the module is never loaded/attached (kldstat shows neither). The malicious data comes from the PCI device's REPORT_LOGICAL_LUNS DMA response at probe time — it is not reachable from any unprivileged userspace syscall. Driving it live would require either (a) a malicious physical/emulated CISS PCI device (a hardware-attacker / VFIO-passthrough threat) or (b) kldload+crafted device (root-only). Per the audit's realism bar this is a hardware/firmware-attacker class finding: valid primitive (confirmed here at the harness level), but no unprivileged local escalation path exists on a default guest.

Fix (fix.diff)

Validate bus < ciss_max_logical_bus and target < CISS_MAX_LOGICAL before indexing, at ciss.c:1393. One logical change; compiles cleanly (-Werror) in the rebuilt ciss.ko.

Fix validation

Built ciss.ko from patched source (with DF-1190/1191/1192 applied) — compiled with -Werror and linked (/usr/obj/usr/src/sys/dev/raid/ciss/ciss.ko, 61664 B), new "logical drive %d has out-of-range address" string present. No live kernel trigger available on the guest (no CISS HW), so the fix is validated at the applies + compiles + closes-the-code-path level (the honest bar for a hardware-only driver bug), fix_status: not_testable.