Re: [PATCH v2 3/3] scsi: libiscsi: validate the task named by a management response
[email protected] Tue, 04 Aug 2026 04:33:31 +0000
| Newsgroups | gmane.linux.scsi |
|---|---|
| Message-ID | <[email protected]> |
Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: Pre-existing issues: - [High] iscsi_complete_pdu() acquires session->lock with spin_lock(), but = can be called from process context, leading to a deadlock against softirqs. -- --- Patch [3]: [PATCH v2 3/3] scsi: libiscsi: validate the task named by a = management response --- commit 5135af06e5540d3c52932cc2310608b06242c034 Author: Yehyeong Lee <[email protected]> scsi: libiscsi: validate the task named by a management response __iscsi_complete_pdu() fetches the task for five response types from one place and checks only that the index resolved. This commit fixes an issue where task->conn could be NULL by requiring the task to be in flight and not a SCSI command. > diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c > index f6e7facf296b2..b686cd2aa4dd2 100644 > --- a/drivers/scsi/libiscsi.c > +++ b/drivers/scsi/libiscsi.c > @@ -1180,7 +1180,7 @@ int __iscsi_complete_pdu(struct iscsi_conn *conn, s= truct iscsi_hdr *hdr, > case ISCSI_OP_SCSI_TMFUNC_RSP: > case ISCSI_OP_NOOP_IN: > task =3D iscsi_itt_to_task(conn, hdr->itt); > - if (!task) > + if (!task || task->state =3D=3D ISCSI_TASK_FREE || task->sc) [Severity: High] This is a pre-existing issue, but could the lock usage in the caller lead to a deadlock? Looking at iscsi_complete_pdu() (which calls __iscsi_complete_pdu()), it us= es spin_lock(&conn->session->lock) instead of spin_lock_bh(). If qla4xxx_task_work() in drivers/scsi/qla4xxx/ql4_os.c is called from a workqueue (process context), it calls iscsi_complete_pdu() without disabl= ing softirqs: drivers/scsi/qla4xxx/ql4_os.c:qla4xxx_task_work() { ... iscsi_complete_pdu(conn, hdr, data, data_len); ... } If a timer interrupt fires on the same CPU while the lock is held, the timer softirq callback iscsi_check_transport_timeouts() will attempt to acquire t= he same lock, resulting in a lock inversion deadlock: drivers/scsi/libiscsi.c:iscsi_check_transport_timeouts() { ... spin_lock(&session->lock); ... } Should iscsi_complete_pdu() use spin_lock_bh() to prevent this? > return ISCSI_ERR_BAD_ITT; > break; > default: --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260804040546.2264= [email protected]?part=3D3