/*
 * DF-3964 trigger sketch — firmware-fed hba config used without validation
 * ========================================================================
 * hptiop_attach() stores the get_config reply verbatim (hptiop.c:1928-1933):
 *   hba->max_requests     = iop_config.max_requests;
 *   hba->max_request_size = iop_config.request_size;
 *   hba->max_sg_count     = iop_config.max_sg_count;
 * then:
 *
 * (1) hptiop.c:1946-1955 — io_dmat is created with
 *         maxsize   = PAGE_SIZE * (hba->max_sg_count - 1)   <-- unsigned math
 *         nsegments = hba->max_sg_count
 *     max_sg_count == 0 (broken/flaky firmware, or corrupted DMA of the
 *     config block) makes maxsize = PAGE_SIZE * 0xffffffff
 *     = 0xFFFFFFFFFFFFF000 on bus_size_t -> an insane tag that either fails
 *     creation (attach dies) or admits huge loads depending on busdma
 *     implementation.
 *
 * (2) hptiop.c:1993-1999 — cam_simq_alloc(hba->max_requests - 1);
 *     max_requests == 0 -> openings = -1 (0xffffffff as u_int) -> SIM
 *     advertises ~4G openings against a 256-entry srb pool. The srb pool
 *     exhaustion path returns CAM_BUSY, so it degrades rather than corrupts,
 *     but the queue accounting is nonsense.
 *
 * (3) hba->max_devices is used for the target-id bound (hptiop.c:2281) and
 *     XPT_PATH_INQ max_target (:2374) — a huge value widens the accepted
 *     target range to a firmware that only backs fewer (soft issue).
 *
 * These are distinct code paths from DF-1313 (which covers the ioctl
 * copyin-ordering + max_request_size *size check* trust).
 *
 * Trigger: attach with an HBA (or emulated device / reflash) whose get_config
 * reply carries max_sg_count=0 or max_requests=0.
 */
int main(void) { return 0; }