Patchwork [3.5.y.z,extended,stable] Patch "target: Fix use-after-free in LUN RESET handling" has been added to staging queue

login
register
mail settings
Submitter Herton Ronaldo Krzesinski
Date Jan. 23, 2013, 4:43 a.m.
Message ID <1358916205-23495-1-git-send-email-herton.krzesinski@canonical.com>
Download mbox | patch
Permalink /patch/214766/
State New
Headers show

Comments

Herton Ronaldo Krzesinski - Jan. 23, 2013, 4:43 a.m.
This is a note to let you know that I have just added a patch titled

    target: Fix use-after-free in LUN RESET handling

to the linux-3.5.y-queue branch of the 3.5.y.z extended stable tree 
which can be found at:

 http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.5.y-queue

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 3.5.y.z tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Herton

------

From 859af1247df8e7a560fb3e4ed0eeed4c69ccfe7e Mon Sep 17 00:00:00 2001
From: Roland Dreier <roland@purestorage.com>
Date: Wed, 2 Jan 2013 12:47:58 -0800
Subject: [PATCH] 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>
[ herton: adjust context ]
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
---
 drivers/target/target_core_transport.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--
1.7.9.5

Patch

diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c
index cf05182..d6c73e8 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -586,9 +586,6 @@  static void transport_lun_remove_cmd(struct se_cmd *cmd)

 void transport_cmd_finish_abort(struct se_cmd *cmd, int remove)
 {
-	if (!(cmd->se_cmd_flags & SCF_SCSI_TMR_CDB))
-		transport_lun_remove_cmd(cmd);
-
 	if (transport_cmd_check_stop_to_fabric(cmd))
 		return;
 	if (remove) {
@@ -4296,6 +4293,8 @@  void transport_send_task_abort(struct se_cmd *cmd)
 	}
 	cmd->scsi_status = SAM_STAT_TASK_ABORTED;

+	transport_lun_remove_cmd(cmd);
+
 	pr_debug("Setting SAM_STAT_TASK_ABORTED status for CDB: 0x%02x,"
 		" ITT: 0x%08x\n", cmd->t_task_cdb[0],
 		cmd->se_tfo->get_task_tag(cmd));