DF-3582 — Type-confused FCPARAM() write in RQCS_RESET_OCCURRED handler (isp.c)

WHAT sys/dev/disk/isp/isp.c:6105-6110, inside isp_parse_status():

    case RQCS_RESET_OCCURRED:
    {
            int chan;
            isp_xs_prt(isp, xs, ISP_LOGWARN, "Bus Reset destroyed command");
            for (chan = 0; chan < isp->isp_nchan; chan++) {
                    FCPARAM(isp, chan)->sendmarker = 1;   /* <-- BUG */
            }

FCPARAM() (ispvar.h:644) casts isp->isp_param to (fcparam *).  On SCSI
cards isp_param is allocated as nchan * sizeof(sdparam) (isp_pci.c:827-832);
fcparam and sdparam are unrelated layouts:

    sizeof(sdparam) =   204   (x86-64, real kernel headers, guest cc 8.3)
    sizeof(fcparam) = 21576   (portdb[512] x 40 dominates)

sendmarker is bit 3 of the first 32-bit word of fcparam, so the write is
a read-modify-write at  isp_param + chan*21576.

REACHABILITY * isp_parse_status() runs for every non-24XX completion — i.e. for ALL parallel SCSI cards (isp_intr, isp.c:5280). * RQCS_RESET_OCCURRED (0x0004, ispmbox.h:728) is the completion status the firmware returns for in-flight commands destroyed by a SCSI bus reset — a routine operational event (power glitch, device hot-plug, watchdog RESET_BUS, malicious target asserting RST). * Single-bus SCSI card (nchan=1): chan=0 write lands in sdparam's unnamed 8-bit pad — type confusion but benign. * DUAL-BUS SCSI card (ISP1080/1240/1280/12160, isp_pci.c:732/749 set nchan=2): chan=1 write lands 21576 bytes into a 408-byte kmalloc — 21,168 bytes PAST the end of the heap allocation.

PROOF (this pack) geom2.c / trigger_df3582.c include the REAL kernel headers (dev/disk/isp/isp_stds.h, ispmbox.h, ispvar.h copied verbatim from the guest's /usr/src) and execute the identical bitfield RMW against a 408-byte buffer placed before a PROT_NONE guard region:

    chan=0: write at +0 OK (in-allocation)
    chan=1: FAULT (SIGSEGV/SEGV) touching 0x8004a5448 =>
            offset 21576 from allocation start
            (21168 past end of 408-byte alloc)

run.log holds the full untrimmed guest session (build + 2 runs + env).

WHY "inconclusive" (not reproduced) The guest has NO QLogic HBA (pciconf shows none, /dev/isp* absent), so the in-kernel path cannot be triggered end-to-end on this machine. What IS proven, with certainty, on the guest with the real kernel structs: - the allocation geometry (204/21576/408), - the write displacement (+21576 for chan=1), - that the write faults/corrupts far outside the allocation. The driver ships in the GENERIC kernel (kldstat -v: pci/isp) and dual-bus firmware modules (isp_1080.ko, isp_12160.ko) ship in /boot/kernel, so the code is live on any machine with such a card.

UPSTREAM Modern FreeBSD deleted this entire legacy parse path (only isp_parse_status_24xx remains, where FCPARAM use is type-correct because 24xx parts are FC-only). The bug is in the ancient FreeBSD revision (isp.c,v 1.168, 2011) that DragonFly carries.

FIX fix.diff — use the existing ISP_SET_SENDMARKER() macro (ispvar.h:646-652) which selects FCPARAM/SDPARAM by IS_FC(), exactly like every other sendmarker write in the driver.

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.