scsi: aacraid: Fix command send race condition
authorBrian King <brking@linux.vnet.ibm.com>
Tue, 29 Aug 2017 15:00:29 +0000 (10:00 -0500)
committerBen Hutchings <ben@decadent.org.uk>
Sun, 26 Nov 2017 13:51:05 +0000 (13:51 +0000)
commita37d7be7a0aafd3aaa224b0ba79f63f55881afb9
treec2badbd554926fe87caac67e34ec93c7526f55a6
parent48dc5149694b5d77d730d6a07e28488883f61500
scsi: aacraid: Fix command send race condition

commit 1ae948fa4f00f3a2823e7cb19a3049ef27dd6947 upstream.

This fixes a potential race condition observed on Power systems.

Several places throughout the aacraid driver call aac_fib_send or
similar to send a command to the aacraid adapter, then check the return
code to determine if the command was actually sent to the adapter, then
update the phase field in the scsi command scratch pad area to track
that the firmware now owns this command.  However, there is nothing that
ensures that by the time the aac_fib_send function returns and we go to
write to the scsi command, that the command hasn't already completed and
the scsi command has been freed.  This was causing random crashes in the
TCP stack which was tracked down to be caused by memory that had been a
struct request + scsi_cmnd being now used for an skbuff. Memory
poisoning was enabled in the kernel to debug this which showed that the
last owner of the memory that had been freed was aacraid and that it was
a struct request.  The memory that was corrupted was the exact data
pattern of AAC_OWNER_FIRMWARE and it was at the same offset that aacraid
writes, which is scsicmd->SCp.phase. The patch below resolves this
issue.

Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Tested-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
Reviewed-by: Dave Carroll <david.carroll@microsemi.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
[bwh: Backported to 3.2:
 - Drop changes to aac_send_hba_fib()
 - Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
drivers/scsi/aacraid/aachba.c