v1 was a single patch for the Reject path. The Sashiko review of it
pointed at two more places where a target-supplied ITT reaches a task
without being checked, and both are now in the series.

1/3 bounds the index from below. A transport that implements
parse_pdu_itt can produce a negative one; be2iscsi does, and forwards an
unsolicited NOP-In from the hardware with the target's ITT intact. I
have no be2iscsi hardware, so this one is argued from source.

2/3 is v1 unchanged: the ITT reflected in a Reject PDU.

3/3 is the same defect at the lookup that five management responses
share. An unsolicited NOP-In naming an unused index dereferences a NULL
task->conn; a Text Response with the same ITT crashes a little later in
iscsi_complete_task().

Measured on 7.2-rc5 with KASAN over a proxy that injects one PDU. Five
attack shapes oops or warn unpatched and none of them do with the
series. Normal I/O, an abort TMF, a rejected NOP-Out ping, a userspace
nop sent over netlink and an iscsid-driven session are unchanged.

v1: 20260803104149.2114414-1-yhlee@isslab.korea.ac.kr

Yehyeong Lee (3):
  scsi: libiscsi: reject a negative task index from parse_pdu_itt
  scsi: libiscsi: validate the ITT reflected in a Reject PDU
  scsi: libiscsi: validate the task named by a management response

 drivers/scsi/libiscsi.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

-- 
2.43.0

Two notes on the Sashiko reviews of 2/3 and 3/3, both marked pre-existing.

On 2/3, the same validation is indeed needed for the other management
responses in __iscsi_complete_pdu() - that is 3/3 in this series. The
second question there, whether an in-flight SCSI read can complete
without transferring data, is the third case in 2/3's changelog: a 1 MiB
read returned 1048576 with none of its buffer written. The task->sc test
is what blocks it.

On 3/3 the reported lock inversion does not hold. iscsi_complete_pdu()
takes back_lock (libiscsi.c:1358), iscsi_check_transport_timeouts() takes
frwd_lock (libiscsi.c:2249). session->lock does not appear in libiscsi.c;
the only mention left is a stale comment at libiscsi.h:131.