[PATCH 0/2] scsi: qedi: bound firmware-reported lengths before they become copy lengths

[Yehyeong Lee]

Two places in qedi take a length out of a completion queue entry and use it
as a memcpy() length without ever comparing it against the buffer it is
read from or the one it is written to.  Both of the masks involved are
0xFFFFFF.

The first is the unsolicited PDU path, where the destination is a 256-byte
array on the stack of the nop-in and async handlers.  The second is the
sense data copy on the SCSI response path, where the source is a 96-byte
coherent DMA allocation.  Both lengths are ones a target can reach: the
unsolicited one by sending a nop-in or an async message whose payload is
larger than a single BDQ buffer, the sense one with any check condition.

I have no FastLinQ hardware, so patch 1 is backed by a KUnit harness that
drives the real copy helper with the two DMA buffers swapped for kmalloc()
of the same size so that KASAN can see them, and patch 2 rests on the sizes
in the source.  Neither patch changes what is delivered for a PDU whose
data segment fits in the buffer it was given.

Yehyeong Lee (2):
  scsi: qedi: bound the data segment length of an unsolicited PDU
  scsi: qedi: bound the sense data length reported by the firmware

 drivers/scsi/qedi/qedi_fw.c | 75 ++++++++++++++++++++++++++-----------
 1 file changed, 51 insertions(+), 24 deletions(-)