Re: [PATCH v4] scsi: mvumi: reject handshake sizes that overflow the list allocations

[Yehyeong Lee]

Both are real.  Neither is fixed in this version; both are fixed in the
series that replaces it:

  [PATCH v5 0/6] scsi: mvumi: bound the values the firmware supplies
  <20261014151914.3632701-1-yhlee@xxxxxxxxxxxxxxxxxx>
  https://lore.kernel.org/linux-scsi/20261014151914.3632701-1-yhlee@xxxxxxxxxxxxxxxxxx/

- mvumi_flush_cache(): confirmed.  device_id is an unsigned char and the
  bound, mhba->max_target_id, comes from the u16 max_devices_support, so a
  reported count of 256 or more never terminates the loop, and that loop
  runs from shutdown, suspend and remove.  Fixed by 6/6 of the series,
  "scsi: mvumi: widen the flush cache loop counter"
  <20261014151914.3632701-7-yhlee@xxxxxxxxxxxxxxxxxx>, which gives the
  counter the type of its bound rather than rejecting the value: the rest
  of the driver already handles counts above 255 -- mvumi_probe_devices()
  walks it with an int and host->max_id is wider too -- so rejecting would
  turn away a working configuration.  frame->device_id is a u16 and
  target_map holds round_up(max_target_id, 8) / 8 bytes, so nothing
  truncates or overruns after the widening, given the reset check 4/6 adds.
  6/6 depends on 4/6 for that reason and its commit message says so.
- mvumi_calculate_checksum(): confirmed.  Fixed by 2/6,
  "scsi: mvumi: reject an out-of-range handshake frame length"
  <20261014151914.3632701-3-yhlee@xxxxxxxxxxxxxxxxxx>, which rejects a
  frame_length that does not fit the handshake page before the checksum
  walks it.  HSP_MAX_SIZE is 48 and the header is 4 bytes, so a
  frame_length above 44 is turned away, well below the 256 that makes the
  counter wrap, and the same patch reads the field once with READ_ONCE() so
  the checked value is the one used.  The counter width is left alone
  there, since the input can no longer reach it.

Looking for the rest of this shape turned up three more, all in the series:
a hotplug event bitmap size that is not held inside the 512-byte event
buffer (3/6), a response frame tag that is checked on the outbound-list
frame but used from the copy made afterwards, with a > instead of >= bound
(5/6), and an inbound or outbound entry size too small to hold the frames
the driver puts in it (folded into 4/6).