# DF-3964 verdict — certain input-validation gap, Low impact

## Reproduced?
No: no HighPoint HBA on the guest (env.txt); the config block is device-fed.

## Analysis
- hptiop.c:1928-1933: all five config fields stored verbatim from the
  device-written block (itl/mv: DMA'd / MMIO-read reply; mvfrey: BAR0 block
  validated only for header size/type at 970-976 — not for the *values*).
- hptiop.c:1951: `PAGE_SIZE * (hba->max_sg_count-1)` — bus_size_t math
  underflows to 0xFFFFFFFFFFFFF000 when max_sg_count==0; tag creation with
  that maxsize either fails (attach abort) or creates a tag whose geometry no
  longer matches the firmware contract.
- hptiop.c:1993/1999: `cam_simq_alloc(hba->max_requests - 1)` with 0 →
  (unsigned)-1 openings; the SIM then believes ~4G commands fit while the srb
  freelist holds 256 — the get_srb failure path (2289-2294) returns CAM_BUSY
  so it degrades (I/O pileup) rather than corrupts.
- Distinct from DF-1313 (ioctl-side copyin ordering + request_size trust).

## Fix
fix.diff validates the three fields at attach (reject max_requests==0, floor
max_sg_count/max_devices at 1).

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