All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Yehyeong Lee" <yhlee@isslab.korea.ac.kr>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v2 2/3] scsi: libiscsi: validate the ITT reflected in a Reject PDU
Date: Tue, 04 Aug 2026 04:30:29 +0000	[thread overview]
Message-ID: <20260804043029.ADA741F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260804040546.2264137-3-yhlee@isslab.korea.ac.kr>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incomplete fix for ITT validation allowing remote denial of service and silent data corruption.
--

--- Patch [2]: [PATCH v2 2/3] scsi: libiscsi: validate the ITT reflected in a Reject PDU ---
commit b86c9905a91963794fe78b0e96f89ab99adb9cb4
Author: Yehyeong Lee <yhlee@isslab.korea.ac.kr>

scsi: libiscsi: validate the ITT reflected in a Reject PDU

This commit fixes an issue where an iSCSI target could cause a kernel panic
or silent data corruption by sending a Reject PDU with an invalid or
inappropriate Initiator Task Tag (ITT). By explicitly validating the ITT
and ensuring the task is active and not a SCSI command, it prevents these
out-of-bounds manipulations.

> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
> index ba3f971279c64..f6e7facf296b2 100644
> --- a/drivers/scsi/libiscsi.c
> +++ b/drivers/scsi/libiscsi.c

[ ... ]

> @@ -1045,8 +1045,11 @@ static int iscsi_handle_reject(struct iscsi_conn *conn, struct iscsi_hdr *hdr,
>  			 * Our nop as ping got dropped. We know the target
>  			 * and transport are ok so just clean up
>  			 */
> -			task = iscsi_itt_to_task(conn, rejected_pdu.itt);
> -			if (!task) {
> +			task = NULL;
> +			if (!iscsi_verify_itt(conn, rejected_pdu.itt))
> +				task = iscsi_itt_to_task(conn, rejected_pdu.itt);
> +			if (!task || task->state == ISCSI_TASK_FREE ||
> +			    task->sc) {

[Severity: High]
This is a pre-existing issue, but does this same validation need to be
applied to other management responses in __iscsi_complete_pdu()?

Looking at __iscsi_complete_pdu(), when handling opcodes like
ISCSI_OP_NOOP_IN or ISCSI_OP_TEXT_RSP, it retrieves the task blindly:

drivers/scsi/libiscsi.c:__iscsi_complete_pdu() {
    ...
    case ISCSI_OP_LOGOUT_RSP:
    case ISCSI_OP_LOGIN_RSP:
    case ISCSI_OP_TEXT_RSP:
    case ISCSI_OP_SCSI_TMFUNC_RSP:
    case ISCSI_OP_NOOP_IN:
        task = iscsi_itt_to_task(conn, hdr->itt);
        if (!task)
            return ISCSI_ERR_BAD_ITT;
        break;
    ...
}

If a target sends one of these opcodes with an ITT pointing to an unused
task, task->conn will be NULL. This can lead to a NULL pointer dereference
when accessing conn->cls_conn in iscsi_nop_out_rsp() or 
iscsi_complete_task().

Similarly, if the ITT points to an active SCSI task, iscsi_complete_task()
could incorrectly force its state to ISCSI_TASK_COMPLETED. Could this allow
an in-flight SCSI read to complete without transferring data?

>  				iscsi_conn_printk(KERN_ERR, conn,
>  						 "Invalid pdu reject. Could "
>  						 "not lookup rejected task.\n");

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260804040546.2264137-1-yhlee@isslab.korea.ac.kr?part=2

  reply	other threads:[~2026-08-04  4:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04  4:05 [PATCH v2 0/3] scsi: libiscsi: validate task lookups driven by target-supplied ITTs Yehyeong Lee
2026-08-04  4:05 ` [PATCH v2 1/3] scsi: libiscsi: reject a negative task index from parse_pdu_itt Yehyeong Lee
2026-08-04  4:05 ` [PATCH v2 2/3] scsi: libiscsi: validate the ITT reflected in a Reject PDU Yehyeong Lee
2026-08-04  4:30   ` sashiko-bot [this message]
2026-08-04  4:05 ` [PATCH v2 3/3] scsi: libiscsi: validate the task named by a management response Yehyeong Lee
2026-08-04  4:33   ` sashiko-bot
2026-08-04  6:24 ` [PATCH v2 0/3] scsi: libiscsi: validate task lookups driven by target-supplied ITTs Yehyeong Lee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260804043029.ADA741F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yhlee@isslab.korea.ac.kr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.