scsi: qla2xxx: Fix memcpy() field-spanning write issue
purex_item.iocb is defined as a 64-element u8 array, but 64 is the
minimum size and it can be allocated larger. This makes it a standard
empty flex array.
This was motivated by field-spanning write warnings during FPIN testing:
https://lore.kernel.org/linux-nvme/
20250709211919.49100-1-bgurney@redhat.com/
> kernel: memcpy: detected field-spanning write (size 60) of single field
> "((uint8_t *)fpin_pkt + buffer_copy_offset)"
> at drivers/scsi/qla2xxx/qla_isr.c:1221 (size 44)
I removed the outer wrapper from the iocb flex array, so that it can be
linked to 'purex_item.size' with '__counted_by'.
These changes remove the default minimum 64-byte allocation, requiring
further changes.
In 'struct scsi_qla_host' the embedded 'default_item' is now followed
by '__default_item_iocb[QLA_DEFAULT_PAYLOAD_SIZE]' to reserve space
that will be used as 'default_item.iocb'. This is wrapped using the
'TRAILING_OVERLAP()' macro helper, which effectively creates a union
between flexible-array member 'default_item.iocb' and
'__default_item_iocb'.
Since 'struct pure_item' now contains a flexible-array member, the
helper must be placed at the end of 'struct scsi_qla_host' to prevent
a '-Wflex-array-member-not-at-end' warning.
'qla24xx_alloc_purex_item()' is adjusted to no longer expect the
default minimum size to be part of 'sizeof(struct purex_item)', the
entire flexible array size is added to the structure size for
allocation.
This also slightly changes the layout of the purex_item struct, as
2-bytes of padding are added between 'size' and 'iocb'. The resulting
size is the same, but iocb is shifted 2-bytes (the original 'purex_item'
structure was padded at the end, after the 64-byte defined array size).
I don't think this is a problem.
Tested-by: Bryan Gurney <bgurney@redhat.com>
Co-developed-by: Chris Leech <cleech@redhat.com>
Signed-off-by: Chris Leech <cleech@redhat.com>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20250813200744.17975-10-bgurney@redhat.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>