mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-11-11 21:38:32 +08:00
72b59d6ee8
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> Cc: stable@vger.kernel.org Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> |
||
---|---|---|
.. | ||
iscsi | ||
loopback | ||
sbp | ||
tcm_fc | ||
Kconfig | ||
Makefile | ||
target_core_alua.c | ||
target_core_alua.h | ||
target_core_configfs.c | ||
target_core_device.c | ||
target_core_fabric_configfs.c | ||
target_core_fabric_lib.c | ||
target_core_file.c | ||
target_core_file.h | ||
target_core_hba.c | ||
target_core_iblock.c | ||
target_core_iblock.h | ||
target_core_internal.h | ||
target_core_pr.c | ||
target_core_pr.h | ||
target_core_pscsi.c | ||
target_core_pscsi.h | ||
target_core_rd.c | ||
target_core_rd.h | ||
target_core_sbc.c | ||
target_core_spc.c | ||
target_core_stat.c | ||
target_core_tmr.c | ||
target_core_tpg.c | ||
target_core_transport.c | ||
target_core_ua.c | ||
target_core_ua.h |