# DF-3732 VERDICT

## Finding
During attach, `ciss_init_pci()` bounds-checks the CISS config table location
(`cofs + sizeof(struct ciss_config_table) > csize` → ENXIO, ciss.c:646-649),
then selects the Performant transport by pointer arithmetic on a second,
**unvalidated** firmware field:

```c
    /* sys/dev/raid/ciss/ciss.c:692-695 */
setup:
    if ((supported_methods & CISS_TRANSPORT_METHOD_PERF) != 0) {
	method = CISS_TRANSPORT_METHOD_PERF;
	sc->ciss_perf = (struct ciss_perf_config *)(cbase + cofs +
	    sc->ciss_cfg->transport_offset);      /* 32-bit FW value, unchecked */
```

`transport_offset` is a u_int32_t read out of adapter-mapped memory
(cissreg.h:414). Nothing constrains it to the BAR window (`csize`). With a
malicious/corrupted controller (or a spoofed Smart Array function on
externally-attacker-reachable PCIe, e.g. Thunderbolt-era chassis),
`sc->ciss_perf` can point anywhere within ~4 GB of the mapping base — and
`ciss_init_perf()` immediately **writes** through it:

```c
    /* sys/dev/raid/ciss/ciss.c:926-946 */
    pc->fetch_count[...] = ...;      /* 8 x u32 writes */
    pc->rq_size  = sc->ciss_max_requests;
    pc->rq_count = 1;
    pc->rq_bank_hi/lo = 0;
    pc->rq[0].rq_addr_hi/lo = ...;   /* host phys addresses written OOB */
```

Impact: arbitrary-offset kernel memory corruption relative to the BAR
mapping (write of semi-controlled content: small integers + host physical
addresses). Threat model is malicious/buggy hardware — the same trust
boundary the rest of this driver's firmware-parsing findings use, but here
there is no unprivileged-local or remote software trigger at all, hence Low.

## Status
- Source-certain (the missing check is unambiguous; FreeBSD upstream has
  the same gap).
- Runtime: **inconclusive** — the audit guest has no HP Smart Array PCI
  device (env.txt: `pciconf -l | grep -i 0e11|103c` → NONE), so neither the
  vulnerable path nor the fix is live-testable.

## Fix validation
- `fix.diff` adds the window check (mirroring the ciss.c:646 pattern) and
  falls back to the SIMPLE transport when it fails.
- `fix_apply.log`: `patch --dry-run` clean on the guest's `/usr/src`;
  `fix_build.log`: `ciss.ko` rebuilt with all 7 ciss pass-2 fixes at
  `-Werror`, link rc=0. No behavioral run possible (no hardware).

**Bottom line: inconclusive at runtime (hardware absent), source-certain
missing bounds check on a firmware-controlled pointer used for writes;
fix compile-validated.**

## 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.