[PATCH v5 0/6] scsi: mvumi: bound the values the firmware supplies

[Yehyeong Lee]

This folds the two mvumi series I have on the list into one and adds what a
full pass over the driver's firmware-supplied values turned up.  It
supersedes

  [PATCH v2 0/2] scsi: mvumi: bound two firmware-supplied lengths
  20261013173145.3412863-1-yhlee@xxxxxxxxxxxxxxxxxx

  [PATCH v4] scsi: mvumi: reject handshake sizes that overflow the list
  allocations
  20261014134104.3528958-1-yhlee@xxxxxxxxxxxxxxxxxx

and both of those can be dropped.

Everything the firmware writes reaches the driver either through the
handshake page, through the event buffer, or through a response frame in
the outbound list.  The patches follow that split:

 1  event buffer: param_count and sense_data_length index fixed arrays in
    mvumi_show_event().
 2  handshake page: frame_length drives the checksum walk, whose counter is
    an unsigned char, so 256 or more never terminates.
 3  event buffer: the hotplug bitmap size drives two find_next_zero_bit()
    scans with nothing holding it inside the 512-byte buffer.
 4  handshake page: the entry sizes and max_io size three allocations, the
    list depth drives the ring index, and a reset reports all of them
    again without reallocating anything.
 5  response frame: the tag indexes tag_cmd[], and the value that is
    checked and the value that is used are separate fetches of
    firmware-writable memory.
 6  handshake page: max_devices_support is a u16 and the loop counter
    mvumi_flush_cache() compares it against is an unsigned char.

Patch 6 depends on patch 4 and patch 5 reads better after it, so the order
matters; 1 to 3 are independent.

I have no mvumi hardware, so none of this is tested on a controller.  Each
patch's reasoning is from the source, and I modelled the arithmetic and the
loop bounds of every case in userspace, including the values that should
still be accepted.

v5:
- one series instead of two; supersedes the two above.
- new: bound the hotplug event bitmap (patch 3).
- new: validate the response frame tag (patch 5).
- patch 4 also rejects an entry size too small to hold the frames the
  driver puts in it, which is what made the max_sg subtraction in
  mvumi_io_attach() wrap.
- new: widen the flush cache loop counter (patch 6), which answers the
  review of the v4 posting above.

Yehyeong Lee (6):
  scsi: mvumi: bound the per-event parameter and sense dumps
  scsi: mvumi: reject an out-of-range handshake frame length
  scsi: mvumi: bound the hotplug event bitmap
  scsi: mvumi: reject handshake sizes that overflow the list allocations
  scsi: mvumi: validate the response frame tag before using it
  scsi: mvumi: widen the flush cache loop counter

 drivers/scsi/mvumi.c | 156 +++++++++++++++++++++++++++++++++++--------
 drivers/scsi/mvumi.h |   3 +
 2 files changed, 132 insertions(+), 27 deletions(-)


base-commit: 24a19b953e2a3d0ea5a8c4951a0ab8f32720c907
-- 
2.43.0