On Wed, 20 May 2020 00:42:17 +1000 Daniel Axtens <dja@xxxxxxxxxx> wrote:
> This looks like a SCSI issue that this has just happened to expose?
> + scsi list
Maybe.
static void arcmsr_handle_virtual_command(struct AdapterControlBlock *acb,
struct scsi_cmnd *cmd)
{
switch (cmd->cmnd[0]) {
case INQUIRY: {
unsigned char inqdata[36];
char *buffer;
struct scatterlist *sg;
if (cmd->device->lun) {
cmd->result = (DID_TIME_OUT << 16);
cmd->scsi_done(cmd);
return;
}
inqdata[0] = TYPE_PROCESSOR;
/* Periph Qualifier & Periph Dev Type */
inqdata[1] = 0;
/* rem media bit & Dev Type Modifier */
inqdata[2] = 0;
/* ISO, ECMA, & ANSI versions */
inqdata[4] = 31;
/* length of additional data */
strncpy(&inqdata[8], "Areca ", 8);
/* Vendor Identification */
>>> strncpy(&inqdata[16], "RAID controller ", 16);
/* Product Identification */
strncpy(&inqdata[32], "R001", 4); /* Product Revision */
sg = scsi_sglist(cmd);
buffer = kmap_atomic(sg_page(sg)) + sg->offset;
memcpy(buffer, inqdata, sizeof(inqdata));
sg = scsi_sglist(cmd);
kunmap_atomic(buffer - sg->offset);
cmd->scsi_done(cmd);
}
break;
That strncpy() will indeed fail to copy the trailing null, but it looks
like that null isn't appropriate in the inquiry data.
So I suspect this is a valid usage of strncpy() and the checking is
just too strict.
otoh if this is the only place where we hit this issue then perhaps we
can switch to memcpy() and get on with life ;)
