Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1660722 > unrolled thread

[PATCH] iscsi-target: Reject immediate data underflow larger than SCSI transfer length

Back to article view | Back to linux.kernel

Contents

  [PATCH] iscsi-target: Reject immediate data underflow larger than SCSI transfer length "Nicholas A. Bellinger" <nab@linux-iscsi.org> - 2017-06-08 06:20 +0200
    Re: [PATCH] iscsi-target: Reject immediate data underflow larger than  SCSI transfer length Bart Van Assche <Bart.VanAssche@sandisk.com> - 2017-06-08 17:50 +0200
      Re: [PATCH] iscsi-target: Reject immediate data underflow larger  than SCSI transfer length "Nicholas A. Bellinger" <nab@linux-iscsi.org> - 2017-06-09 09:00 +0200

#1660722 — [PATCH] iscsi-target: Reject immediate data underflow larger than SCSI transfer length

From: Nicholas Bellinger <nab@linux-iscsi.org>

When iscsi WRITE underflow occurs there are two different scenarios
that can happen.

Normally in practice, when an EDTL vs. SCSI CDB TRANSFER LENGTH
underflow is detected, the iscsi immediate data payload is the
smaller SCSI CDB TRANSFER LENGTH.

That is, when a host fabric LLD is using a fixed size EDTL for
a specific control CDB, the SCSI CDB TRANSFER LENGTH and actual
SCSI payload ends up being smaller than EDTL.  In iscsi, this
means the received iscsi immediate data payload matches the
smaller SCSI CDB TRANSFER LENGTH, because there is no more
SCSI payload to accept beyond SCSI CDB TRANSFER LENGTH.

However, it's possible for a malicous host to send a WRITE
underflow where EDTL is larger than SCSI CDB TRANSFER LENGTH,
but incoming iscsi immediate data actually matches EDTL.

In the wild, we've never had a iscsi host environment actually
try to do this.

For this special case, it's wrong to truncate part of the
control CDB payload and continue to process the command during
underflow when immediate data payload received was larger than
SCSI CDB TRANSFER LENGTH, so go ahead and reject and drop the
bogus payload as a defensive action.

Note this potential bug was originally relaxed by the following
for allowing WRITE underflow in MSFT FCP host environments:

   commit c72c5250224d475614a00c1d7e54a67f77cd3410
   Author: Roland Dreier <roland@purestorage.com>
   Date:   Wed Jul 22 15:08:18 2015 -0700

      target: allow underflow/overflow for PR OUT etc. commands

Cc: Roland Dreier <roland@purestorage.com>
Cc: Mike Christie <mchristi@redhat.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
---
 drivers/target/iscsi/iscsi_target.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/target/iscsi/iscsi_target.c b/drivers/target/iscsi/iscsi_target.c
index c025451..3fdca2c 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -1279,6 +1279,18 @@ int iscsit_process_scsi_cmd(struct iscsi_conn *conn, struct iscsi_cmd *cmd,
 	 */
 	if (dump_payload)
 		goto after_immediate_data;
+	/*
+	 * Check for underflow case where both EDTL and immediate data payload
+	 * exceeds what is presented by CDB's TRANSFER LENGTH, and what has
+	 * already been set in target_cmd_size_check() as se_cmd->data_length.
+	 *
+	 * For this special case, fail the command and dump the immediate data
+	 * payload.
+	 */
+	if (cmd->first_burst_len > cmd->se_cmd.data_length) {
+		cmd->sense_reason = TCM_INVALID_CDB_FIELD;
+		goto after_immediate_data;
+	}
 
 	immed_ret = iscsit_handle_immediate_data(cmd, hdr,
 					cmd->first_burst_len);
-- 
1.9.1

[toc] | [next] | [standalone]

#1661410 — Re: [PATCH] iscsi-target: Reject immediate data underflow larger than SCSI transfer length

On Thu, 2017-06-08 at 04:21 +0000, Nicholas A. Bellinger wrote:
> +	/*
> +	 * Check for underflow case where both EDTL and immediate data payload
> +	 * exceeds what is presented by CDB's TRANSFER LENGTH, and what has
> +	 * already been set in target_cmd_size_check() as se_cmd->data_length.
> +	 *
> +	 * For this special case, fail the command and dump the immediate data
> +	 * payload.
> +	 */
> +	if (cmd->first_burst_len > cmd->se_cmd.data_length) {
> +		cmd->sense_reason = TCM_INVALID_CDB_FIELD;
> +		goto after_immediate_data;
> +	}

A quote from the iSCSI RFC (https://tools.ietf.org/html/rfc5048):

   If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in the
   SCSI Response PDU as specified in [RFC3720].  The Residual Count MUST
   be set to the numerical value of (EDTL - SPDTL).

Sorry but I don't think that sending TCM_INVALID_CDB_FIELD back to the
initiator is compliant with the iSCSI RFC. Please note that a fix that is
compliant with the iSCSI RFC is present in the following patch series: [PATCH
00/33] SCSI target driver patches for kernel v4.13, 23 May 2017
(https://www.spinics.net/lists/target-devel/msg15370.html).

Bart.

[toc] | [prev] | [next] | [standalone]

#1661986 — Re: [PATCH] iscsi-target: Reject immediate data underflow larger than SCSI transfer length

On Thu, 2017-06-08 at 15:37 +0000, Bart Van Assche wrote:
> On Thu, 2017-06-08 at 04:21 +0000, Nicholas A. Bellinger wrote:
> > +	/*
> > +	 * Check for underflow case where both EDTL and immediate data payload
> > +	 * exceeds what is presented by CDB's TRANSFER LENGTH, and what has
> > +	 * already been set in target_cmd_size_check() as se_cmd->data_length.
> > +	 *
> > +	 * For this special case, fail the command and dump the immediate data
> > +	 * payload.
> > +	 */
> > +	if (cmd->first_burst_len > cmd->se_cmd.data_length) {
> > +		cmd->sense_reason = TCM_INVALID_CDB_FIELD;
> > +		goto after_immediate_data;
> > +	}
> 
> A quote from the iSCSI RFC (https://tools.ietf.org/html/rfc5048):
> 
>    If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in the
>    SCSI Response PDU as specified in [RFC3720].  The Residual Count MUST
>    be set to the numerical value of (EDTL - SPDTL).
> 
> Sorry but I don't think that sending TCM_INVALID_CDB_FIELD back to the
> initiator is compliant with the iSCSI RFC.

Alas, the nuance of what this patch actually does was missed when you
cut the context.

First, a bit of history.  LIO has rejected underflow for all WRITEs for
the first ~12.5 years of RFC-3720, and in the context of iscsi-target
mode there has never been a single host environment that ever once
cared.

Since Roland's patch to allow underflow for control CDBs in v4.3+ opened
this discussion for control CDBs with a WRITE payload in order to make
MSFT/FCP cert for PERSISTENT_RESERVE_OUT happy, the question has become
what control CDB WRITE underflow cases should we allow..?

The point with this patch is when a host is sending a underflow with a
iscsi immediate data payload that exceeds SCSI transfer length, it's a
bogus request with a garbage payload.  It's a garbage payload because
the SCSI CDB itself obviously doesn't want anything to do it.

I'm very dubious of any host environment who's trying to do this for any
CDB, and expects achieve expected results.

Of course, since v4.3+ normal overflow where SCSI transfer length
matches the iscsi immediate data payload just works with or without this
patch.

So to that extent, I'm going to push this patch as a defensive fix for
v4.3+, to let those imaginary iscsi host environments know they being
very, very naughty.

>  Please note that a fix that is
> compliant with the iSCSI RFC is present in the following patch series: [PATCH
> 00/33] SCSI target driver patches for kernel v4.13, 23 May 2017
> (https://www.spinics.net/lists/target-devel/msg15370.html).

So I might still consider this as a v4.13-rc item for control CDB
underflow, but no way as stable material.

Also, there is certainly no way I'm going to allow a patch to randomly
enable underflow/overflow for all WRITE non control CDBs tree-wide
across all fabric drivers, because 1) no host environments actually care
about this, and 2) it's still dangerous to do for all fabrics without
some serious auditing.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web