# DF-2472 — ISP_FC_GETDINFO ioctl missing channel bounds check

## Verdict: NOT REPRODUCED (HW-gated) — source bug CONFIRMED

## Hardware gate

No QLogic ISP (FC/SCSI) HBA in guest: `kldstat` shows only kernel/ehci/xhci;
`pciconf -l` shows no QLogic device; `camcontrol devlist` shows only QEMU DVD-ROM.
The isp driver and its `/dev/ispN` ioctl surface do not exist on this guest.

## Source trace (confirmed real bug)

**File:** `sys/dev/disk/isp/isp_freebsd.c:471-495`

The `ISP_FC_GETDINFO` ioctl handler validates `ifc->loopid` against `MAX_FC_TARG`
(line 479) but **never validates `ifc->chan`** before indexing `FCPARAM(isp, ifc->chan)`
at line 483. Every other channel-accepting ioctl in the same file has an explicit
guard: `ISP_GETROLE` (line 378), `ISP_SETROLE` (line 392), `ISP_RESCAN` (line 441),
`ISP_FC_LIP` (line 458), `ISP_FC_GETHINFO` (line 535), `ISP_TSK_MGMT` (line 576) —
all check `if (chan < 0 || chan >= isp->isp_nchan)`. This one omits it.

For nearly every FC card `isp_nchan=1`, so any `chan >= 1` reads past the
`fcparam` allocation (~25KB struct). `ifc->chan` is a 6-bit bitfield (0..63).

## Fix

Added the same `chan < 0 || chan >= isp->isp_nchan` guard that sibling ioctls use.
See `fix.diff`.

## Impact (on HW that has the HBA)

Medium — kernel heap OOB read / info leak of up to ~30 bytes per call via the
`portdb[loopid]` dereference. Device node is `0600 root:operator`, so operator-group
access suffices.