From nobody Sat Jul 25 16:19:20 2026 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 945A32DF6F4 for ; Thu, 16 Jul 2026 06:59:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784185151; cv=none; b=IKr4egnPJyPCHMrWPTUhZnOsRpURhEGtVwU7b0nH318brf4Os0HLKMNbaQso9V3okJEGkIkclYXe0ovydbR5JFnJV1LzsXRO2zvPHAgj2UYWa3ONcESBGrocUr9wRKuc7cvGsxZUbPk7FDdsrrNIeCegRdypkiOP5T50+dL5ZoQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784185151; c=relaxed/simple; bh=1vybAkZ2wMgVaOzHa2qygLuGlC3TJoH/uFlRzZYKiTQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XuqxYssVnzOWKBxUNWPqrvj/8rtDnHMypZtIJkrEJnkXiCA6ep55iEBjVckw3+7H85EmOy7sfnBw80f7T5+xJw/eZBZ+f+U7BSd2sEyE4GwqAD4slGmVvuxioKBcwZjsqD7pKsA4PSo4ENAi0OWBPHqaISSJ1hbdpcH0uhk/WhM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=KYioNWKY; arc=none smtp.client-ip=209.85.210.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KYioNWKY" Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-84847482584so216240b3a.0 for ; Wed, 15 Jul 2026 23:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784185149; x=1784789949; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Av94P2V8NtTmuihxtjhBFmg2tcbDiYUZN4BJgJSyKHU=; b=KYioNWKYv5WQRWOeqJxObBFZSPr19OW2STAXI8cGlE6GudKW5Au7NH7aTvGHlgTuDM D+h7Xj85mpVVpXn3aNCtpCJswmtw3CiNZKdwu+AcXAJhNgWQ8rb21lEnCcLSdEj+wYOe r1RWXSDJZsGNNntTYqZMcaVbDMjnibEdVHS/GnaRThL7r2r+UdjceFKlzWls9olog/62 52aER6tNTtBp2GUvGL+OBWYVLqJ9uNrV4yggMNh+AD87JMtMnhjpHl4g8q3FZc6IEOTJ RLYPw7rLiAC1CP7amuSwQoLemgLLOpsvh36wiLvq78mPNe+1FHiITzf78t0TLmDCA/gT Uo3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784185149; x=1784789949; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=Av94P2V8NtTmuihxtjhBFmg2tcbDiYUZN4BJgJSyKHU=; b=I0VoBwdcZ/AtkSrpQ16ezD+xIDAWT7jChWP0ywX+RuU42suUFANrZXpomN3bxedk0P OVRYEMykQ9CrfPgtmfc9FF/bkBiLepzEkeKcq9pW9W5vs0XebVUy76o74ct1KyLYzGV3 ssi2SMYTEtvZrW6Gvj2NWNXWQbv+BgHnkwdenLUzl3NaF3ynONIZFxzrcK3WwxSHwFFz tW4Aq+q580z4T8mLK3xkPVPFdJg48i+nfYsMGydLRCgGJRfyF3jJOW2UWCQyjf2D2DRW m0dc2/gsass7F7alvwwDZr5wtY2GMK/nVmIr8QDW1RIt6usA/780s4NhpjiT4rPiZ8hH 8N5g== X-Forwarded-Encrypted: i=1; AHgh+Ros068vNcEDefdYdDSTrfiFapXkb4cZF9zvOKRmxd9/WEd1YzgwZbOneTMdVRcN1hsdvlYJADCPasmT6zo=@vger.kernel.org X-Gm-Message-State: AOJu0YxP34nqeIm5K2K2nGzt2DkFC0pBdbpT/gjUASS1knEzEMrU/knr v6a5jHProEQWgt5RGt7mRQZ4HEKsqaZkGn4PoUYFAHsX/MDYcb00/29J X-Gm-Gg: AfdE7cknp0XplO+EV4UbIhZ3GVeHuzGTvCThE3ZEebdUO9u0Db1MY3fmZV/hhObQORL ad/sqigNYvz6B2aMw9Qam1EMmROurY+Cd2VIhOSGyUMlh4UDGpUX+msd7xBMjppuo2OJkfTI/LT an8hJQin0o5Y931t/ovjpTu1D3P8OIk9th7FQZhGFsZZtGUUR8WnpXwzoL8S3mkfPe+fqsVJIk9 32fD1QAUonly+tosVQW3aaQfcu/HC+vvv24nOgyZjWKbKVvLHfcKDoU5ne3l2OusDYEZKCejj17 i4AtPr2xTOV6eZghKkxwSTdBbPvMOiw1LuVU9mea/hiJxKY1YkN4EvN5JdSK8dgm9Nq8b+xYKmV /83N9KyA7tMznX2Qqidx/XTfPWFcrOS08IFizdqv5B9ijWs8eIMOOFZjbFf/dkvORRXGjvkvwxC A0WELGm/FiMY2mf2hBtAizkvXdxVwvTU6+eff5p00v90aLsakdl35oYxAeTFPml/Ef0UAc0b/rm 4jPFSpLjIn8zc7q X-Received: by 2002:a05:6a00:14d4:b0:847:888f:9b0f with SMTP id d2e1a72fcca58-84beb1a602fmr1332854b3a.15.1784185148733; Wed, 15 Jul 2026 23:59:08 -0700 (PDT) Received: from nugod-NUC15CRHU5.tail9f095a.ts.net ([218.237.104.87]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84a4f7dadcfsm4278643b3a.48.2026.07.15.23.59.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jul 2026 23:59:08 -0700 (PDT) From: HyeongJun An To: Chris Leech , Mike Christie , Lee Duncan , "Martin K . Petersen" , "James E . J . Bottomley" Cc: open-iscsi@googlegroups.com, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, HyeongJun An Subject: [PATCH v2] scsi: libiscsi_tcp: bound SCSI Response data segment to the connection buffer Date: Thu, 16 Jul 2026 15:58:48 +0900 Message-ID: <20260716065848.1653431-1-sammiee5311@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260710050645.1194212-1-sammiee5311@gmail.com> References: <20260710050645.1194212-1-sammiee5311@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" iscsi_tcp_hdr_dissect() receives the data segment of several PDU types into the fixed-size conn->data buffer, which is allocated for ISCSI_DEF_MAX_RECV_SEG_LEN (8192) bytes. For the LOGIN_RSP, TEXT_RSP, REJECT and ASYNC_EVENT opcodes the dissect path already rejects a PDU whose DataSegmentLength exceeds that buffer. The SCSI Command Response (ISCSI_OP_SCSI_CMD_RSP) path also copies its data segment (sense/response data) into conn->data via iscsi_tcp_data_recv_prep(), but it does so without the same check. The only upstream bound on in.datalen is conn->max_recv_dlength, the initiator's advertised MaxRecvDataSegmentLength, which is commonly negotiated well above 8192 (open-iscsi defaults to 262144). A target that returns a SCSI Response with a DataSegmentLength between 8193 and max_recv_dlength therefore overflows the 8192-byte conn->data buffer. Once the same bound applies, ISCSI_OP_SCSI_CMD_RSP is handled exactly like those responses: bound the data segment, receive it into conn->data when present, and otherwise complete the PDU with no data. Fold the opcode into that case group rather than duplicating the check. Fixes: a081c13e39b5 ("[SCSI] iscsi_tcp: split module into lib and lld") Suggested-by: Chris Leech Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Acked-by: Chris Leech --- v2: Fold ISCSI_OP_SCSI_CMD_RSP into the LOGIN_RSP/TEXT_RSP/REJECT/ ASYNC_EVENT case group instead of duplicating the bounds check, as suggested by Chris Leech. The handling is identical: both bound the data segment to conn->data, receive it when present, and otherwise complete the PDU with no data (the latter via the LOGOUT_RSP fallthrough). No functional change from v1. v1: https://lore.kernel.org/all/20260710050645.1194212-1-sammiee5311@gmail.= com/ drivers/scsi/libiscsi_tcp.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/scsi/libiscsi_tcp.c b/drivers/scsi/libiscsi_tcp.c index e90805ba868f..7223bb18b048 100644 --- a/drivers/scsi/libiscsi_tcp.c +++ b/drivers/scsi/libiscsi_tcp.c @@ -752,13 +752,6 @@ iscsi_tcp_hdr_dissect(struct iscsi_conn *conn, struct = iscsi_hdr *hdr) rc =3D __iscsi_complete_pdu(conn, hdr, NULL, 0); spin_unlock(&conn->session->back_lock); break; - case ISCSI_OP_SCSI_CMD_RSP: - if (tcp_conn->in.datalen) { - iscsi_tcp_data_recv_prep(tcp_conn); - return 0; - } - rc =3D iscsi_complete_pdu(conn, hdr, NULL, 0); - break; case ISCSI_OP_R2T: if (ahslen) { rc =3D ISCSI_ERR_AHSLEN; @@ -766,6 +759,7 @@ iscsi_tcp_hdr_dissect(struct iscsi_conn *conn, struct i= scsi_hdr *hdr) } rc =3D iscsi_tcp_r2t_rsp(conn, hdr); break; + case ISCSI_OP_SCSI_CMD_RSP: case ISCSI_OP_LOGIN_RSP: case ISCSI_OP_TEXT_RSP: case ISCSI_OP_REJECT: --=20 2.43.0