target: Fix use-after-free in LUN RESET handling
authorRoland Dreier <roland@purestorage.com>
Wed, 2 Jan 2013 20:47:58 +0000 (12:47 -0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 21 Jan 2013 19:44:33 +0000 (11:44 -0800)
commitf52375e9fcb897c1b5c1741b0531debd617a4a67
tree5550d32a0f3d68de03b7b92de0f68407b3c36065
parent6a153ea0afa8f709961203f2d3e56260df3d257b
target: Fix use-after-free in LUN RESET handling

commit 72b59d6ee8adaa51f70377db0a1917ed489bead8 upstream.

If a backend IO takes a really long then an initiator might abort a
command, and then when it gives up on the abort, send a LUN reset too,
all before we process any of the original command or the abort.  (The
abort will wait for the backend IO to complete too)

When the backend IO final completes (or fails), the abort handling
will proceed and queue up a "return aborted status" operation.  Then,
while that's still pending, the LUN reset might find the original
command still on the LUN's list of commands and try to return aborted
status again, which leads to a use-after free when the first
se_tfo->queue_status call frees the command and then the second
se_tfo->queue_status call runs.

Fix this by removing a command from the LUN state_list when we first
are about to queue aborted status; we shouldn't do anything
LUN-related after we've started returning status, so this seems like
the correct thing to do.

Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/target/target_core_transport.c