From: sashiko-bot@kernel.org
To: "HyeongJun An" <sammiee5311@gmail.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] scsi: libiscsi_tcp: bound SCSI Response data segment to the connection buffer
Date: Fri, 10 Jul 2026 05:17:04 +0000 [thread overview]
Message-ID: <20260710051704.A25541F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260710050645.1194212-1-sammiee5311@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Medium] In `iscsi_scsi_cmd_rsp()`, an incorrect bounds check allows a malicious or compromised iSCSI target to leak up to 2 bytes of uninitialized kernel memory (or previous packet data) into the SCSI sense buffer via a crafted `CHECK_CONDITION` response.
--
--- Patch [1]: [PATCH] scsi: libiscsi_tcp: bound SCSI Response data segment to the connection buffer ---
commit 997ca9836cebc0e8267dfdbdc7d5ae21d710b9fd
Author: HyeongJun An <sammiee5311@gmail.com>
scsi: libiscsi_tcp: bound SCSI Response data segment to the connection buffer
iscsi_tcp_hdr_dissect() receives the data segment of several PDU types
into the fixed-size conn->data buffer. This commit applies bounds
checking for the SCSI Command Response path before copying the data
segment to prevent overflowing the 8192-byte buffer.
> diff --git a/drivers/scsi/libiscsi_tcp.c b/drivers/scsi/libiscsi_tcp.c
> index 60cb6dc3c6f09..ef28543def9e8 100644
> --- a/drivers/scsi/libiscsi_tcp.c
> +++ b/drivers/scsi/libiscsi_tcp.c
> @@ -720,6 +720,18 @@ iscsi_tcp_hdr_dissect(struct iscsi_conn *conn, struct iscsi_hdr *hdr)
> spin_unlock(&conn->session->back_lock);
> break;
> case ISCSI_OP_SCSI_CMD_RSP:
> + /*
> + * Sense/response data is received into conn->data, so bound
> + * it to that buffer like the responses handled below.
> + */
> + if (tcp_conn->in.datalen > ISCSI_DEF_MAX_RECV_SEG_LEN) {
[Severity: Medium]
This is a pre-existing issue, but while looking at how sense data is read
from conn->data, I noticed a potential out-of-bounds read in
drivers/scsi/libiscsi.c:iscsi_scsi_cmd_rsp():
senselen = get_unaligned_be16(data);
if (datalen < senselen)
goto invalid_datalen;
memcpy(sc->sense_buffer, data + 2,
min_t(uint16_t, senselen, SCSI_SENSE_BUFFERSIZE));
Does this code read past the end of the received data? If datalen is exactly
equal to senselen, the memcpy copies from data + 2, which could read 2 bytes
past the valid data in the buffer and expose uninitialized or stale memory
into the SCSI sense buffer. Should the bounds check be datalen < senselen + 2?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260710050645.1194212-1-sammiee5311@gmail.com?part=1
prev parent reply other threads:[~2026-07-10 5:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 5:06 [PATCH] scsi: libiscsi_tcp: bound SCSI Response data segment to the connection buffer HyeongJun An
2026-07-10 5:17 ` sashiko-bot [this message]
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=20260710051704.A25541F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=sammiee5311@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
/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.