As the comment explains, we have a race between dropping the refcount to zero and actually removing the session from lookup tables. Plug this by checking the refcount on lookup. Signed-off-by: Joern Engel <joern@xxxxxxxxx> --- drivers/scsi/qla2xxx/tcm_qla2xxx.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/drivers/scsi/qla2xxx/tcm_qla2xxx.c b/drivers/scsi/qla2xxx/tcm_qla2xxx.c index 09a70aa..b1bfa08 100644 --- a/drivers/scsi/qla2xxx/tcm_qla2xxx.c +++ b/drivers/scsi/qla2xxx/tcm_qla2xxx.c @@ -1300,6 +1300,20 @@ static struct qla_tgt_sess *tcm_qla2xxx_find_sess_by_s_id( return NULL; } + /* + * We drop the hardware_lock between dropping the reference count to + * zero and removing the session from the btree. Therefore it + * is possible to successfully lookup a session after it has been + * scheduled for removal, but before actual removal. Result is pretty + * good chance of dereferencing freed memory in qlt_issue_task_mgmt. + * + * Proper fix would be to atomically drop the refcount and remove the + * session from all data structures that would allow lookup. Until + * then this tasteless hack shall suffice. + */ + if (atomic_read(&nacl->qla_tgt_sess->se_sess->sess_kref.refcount) == 0) + return NULL; + return nacl->qla_tgt_sess; } @@ -1412,6 +1426,20 @@ static struct qla_tgt_sess *tcm_qla2xxx_find_sess_by_loop_id( return NULL; } + /* + * We drop the hardware_lock between dropping the reference count to + * zero and removing the session from lport_loopid_map. Therefore it + * is possible to successfully lookup a session after it has been + * scheduled for removal, but before actual removal. Result is pretty + * good chance of dereferencing freed memory in qlt_issue_task_mgmt. + * + * Proper fix would be to atomically drop the refcount and remove the + * session from all data structures that would allow lookup. Until + * then this tasteless hack shall suffice. + */ + if (atomic_read(&nacl->qla_tgt_sess->se_sess->sess_kref.refcount) == 0) + return NULL; + return nacl->qla_tgt_sess; } -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
