# DF-3963 verdict — certain source gap, device-fed, Low impact on host memory

## Reproduced?
No: no mv-family HighPoint HBA on the guest (env.txt).

## Analysis (path:line)
- hptiop.c:232 — `outbound_tail = BUS_SPACE_RD4_MV2(outbound_tail)` device
  register; :236-239 uses it unmasked as `outbound_q[outbound_tail]` offset
  (BAR2 + 0x1040 + 8*tail) for `bus_space_read_region_4(..., 2)`.
- hptiop.c:254 — `inbound_head = BUS_SPACE_RD4_MV2(inbound_head)`; :260-262
  writes 8 bytes of `p` (host phys addr | MVIOP flags) at
  `inbound_q[inbound_head]` (BAR2 + 0x40 + 8*head), unmasked.
- Wrap checks (:243, :257) happen only AFTER use and only for the +1 value —
  the device-provided base is never bounded by MVIOP_QUEUE_LEN (512,
  hptiop.h:96; arrays at hptiop.h:105-106).
- Both call sites run on the I/O path (`hptiop_drain_outbound_queue_mv`
  :722-733, `hptiop_post_*` mv writes) — reachable from ordinary I/O once the
  register is bad.

## Why Low
The corrupted window is PCI MMIO space, not host RAM: realistic outcomes are
a bus error/panic (DoS) or clobbering another device's registers. Same
device-trust threat model as DF-1312 (rated Low). Fix is a two-line mask.

## Fix
fix.diff masks both device-fed pointers with `& (MVIOP_QUEUE_LEN - 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.