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)
committerMartin K. Petersen <martin.petersen@oracle.com>
Wed, 30 Aug 2017 01:34:04 +0000 (21:34 -0400)
commit1ae948fa4f00f3a2823e7cb19a3049ef27dd6947
tree6a5a77b4881b65e349be008a3f7c48287d0043bb
parentfa2d9d6e894e096678a50ef0f65f7a8c3d8a40b8
scsi: aacraid: Fix command send race condition

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.

Cc: <stable@vger.kernel.org>
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>
drivers/scsi/aacraid/aachba.c