]> git.itanic.dy.fi Git - linux-stable/commit
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)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 27 Sep 2017 12:43:17 +0000 (14:43 +0200)
commit7192ae0240168baa53e26ffdff44b7d69bc101b9
tree647006fa8b51f2945b15d3317eb05ae0cac76880
parent9e071695a5be9ca758cc5c1d1b92ee98c4e8df1a
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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/scsi/aacraid/aachba.c