DF-3961 — hptiop SG-capacity heap overflow into srb->req[600] (non-highmem itl/mv/mvfrey)

File: sys/dev/raid/hptiop/hptiop.c (pass 2; knowns DF-1311/1312/1313 excluded)

What

hptiop_post_req_itl (non-HIGH_MEM branch), hptiop_post_req_mv and hptiop_post_req_mvfrey write nsegs SG entries into ((struct hpt_iop_request_scsi_command *)srb)->sg_list — the front of the fixed 600-byte srb->req[] DMA-coherent buffer. Capacity is 34 entries (offsetof(sg_list)=48; (600−48)/16=34); the only runtime gate is nsegs > hba->max_sg_count (hptiop.c:2660) where max_sg_count is taken verbatim from the HBA firmware (hptiop.c:1923–1933), and io_dmat is created with nsegments = max_sg_count (hptiop.c:1952). If the firmware reports ≥35, any CCB with ≥35 segments overwrites srb->hba (offset 600), srb->ccb, srb->next, srb->dma_map, srb->phy_addr (offsets 608–639) and then the adjacent srb (stride 672). The completion callbacks then do ccb = (union ccb *)srb->ccb; … xpt_done(ccb) — wild-pointer deref of physically-shaped values.

Distinct from DF-1311, which covers only the stack local req in the HIGH_MEM_ACESS branch of hptiop_post_req_itl (hptiop.c:2417–2457).

Build / Run (hardware recipe)

See trigger.c. No build on the audit guest: guest has no HighPoint HBA (env.txt). On a host with a (misbehaving) RR3xxx/4xxx reporting max_sg_count ≥ 35: 1. kldload hptiop (module ships in /boot/kernel/hptiop.ko) 2. issue ≥35-segment CCB (CAM_SCATTER_VALID originator, or >136 KB I/O)

Expected

Kernel memory corruption of the srb soft structures → panic on completion (xpt_done on forged ccb) or silent slab corruption.

Honesty

Reachability on this platform is marginal: MAXPHYS=128 KB pins the load path at ≤34 segments (scsi_da.c:1248), and no in-tree initiator uses CAM_SCATTER_VALID. The missing capacity bound is certain; exploitation additionally requires firmware to report ≥35 and a ≥35-segment originator.

DF-3961 verdict — source-certain missing bound, marginal platform reachability

Reproduced?

No. The audit guest has no HighPoint PCI device (pciconf: no vendor 0x1103 — env.txt). hptiop.ko is present in /boot/kernel and one kldload away on any host with the hardware, but the trigger additionally needs the HBA firmware to report max_sg_count ≥ 35 (device-fed get_config reply, hptiop.c:1923–1933 stores it verbatim) and a CCB with ≥35 segments.

Why the bug is real (path:line)

• Buffer: srb->req[HPT_SRB_MAX_REQ_SIZE=600] (sys/dev/raid/hptiop/hptiop.h:42, struct hpt_iop_srb at hptiop.h:452–461: req at 0, hba ptr at 600, ccb at 608, next at 616, dma_map at 624, phy_addr at 632, srb_flag 640, index 644; HPT_SRB_MAX_SIZE stride = 672).
• Sinks: hptiop.c:2471–2481 (itl non-highmem), 2539–2547 (mv), 2593–2601 (mvfrey) — psg = req->sg_list (offset 48 in srb), loop writes nsegs*16 bytes; entry 34 lands on [592,608) → srb->hba corrupted at nsegs=35, srb->ccb/dma_map at 36–37.
• Only bound: nsegs > hba->max_sg_count (hptiop.c:2660); io_dmat built with nsegments=max_sg_count (hptiop.c:1946–1959) so the DMA layer enforces the same firmware value, never the buffer capacity.
• DF-1311 covered the stack req of the HIGH_MEM_ACESS branch only (hptiop.c:2417–2457); this heap variant is a different sink and reaches all three families.

Reachability analysis (why severity is Medium, not High)

• scsi_da.c:1248 pins disk I/O to MAXPHYS=128 KB (x86_64) → bus_dmamap_load yields ≤ 33 segments (+1 for a 4 GB boundary split) = ≤34 → no overflow from ordinary disk I/O even with permissive firmware.
• CAM_SCATTER_VALID path (hptiop.c:2329–2342) passes sglist_cnt through unfiltered, but no in-tree DragonFly initiator sets CAM_SCATTER_VALID (grep: only the definition in cam_ccb.h).
• ⇒ overflow requires firmware reporting ≥35 AND a ≥35-segment originator (out-of-tree/future periph, or a kernel with MAXPHYS > 136 KB).

Fix

fix.diff clamps the firmware value to the real capacity at attach (HPT_SRB_MAX_SG_COUNT = 34), which simultaneously bounds post_scsi_command, io_dmat nsegments and the maxsize computation. git apply --check passes against pristine sys/.

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.