Re: FAILED: patch [PATCH] target: Add range checking to UNMAP emulation failed to apply to 3.5-stable tree

2012-08-13 Thread Greg KH
On Wed, Aug 01, 2012 at 02:01:21AM +0100, Ben Hutchings wrote:
 On Tue, 2012-07-31 at 11:11 -0700, gre...@linuxfoundation.org wrote:
  The patch below does not apply to the 3.5-stable tree.
  If someone wants it applied there, or to any other stable or longterm
  tree, then please email the backport, including the original git commit
  id to stable@vger.kernel.org.
 [...]
 
 Here are the versions I applied to 3.2.y, for this and the following 3
 target changes.  The ordering is:
 
 target-add-range-checking-to-unmap-emulation.patch
 target-fix-reading-of-data-length-fields-for-unmap-commands.patch
 target-fix-possible-integer-underflow-in-unmap-emulation.patch
 target-check-number-of-unmap-descriptors-against-our-limit.patch
 
 These also apply on top of 3.5 (with context reduced to 2 for
 target-fix-reading-of-data-length-fields-for-unmap-commands.patch) and
 build cleanly.

Many thanks, that worked wonderfully.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: FAILED: patch [PATCH] target: Add range checking to UNMAP emulation failed to apply to 3.5-stable tree

2012-08-13 Thread Nicholas A. Bellinger
On Mon, 2012-08-13 at 11:33 -0700, Greg KH wrote:
 On Wed, Aug 01, 2012 at 02:01:21AM +0100, Ben Hutchings wrote:
  On Tue, 2012-07-31 at 11:11 -0700, gre...@linuxfoundation.org wrote:
   The patch below does not apply to the 3.5-stable tree.
   If someone wants it applied there, or to any other stable or longterm
   tree, then please email the backport, including the original git commit
   id to stable@vger.kernel.org.
  [...]
  
  Here are the versions I applied to 3.2.y, for this and the following 3
  target changes.  The ordering is:
  
  target-add-range-checking-to-unmap-emulation.patch
  target-fix-reading-of-data-length-fields-for-unmap-commands.patch
  target-fix-possible-integer-underflow-in-unmap-emulation.patch
  target-check-number-of-unmap-descriptors-against-our-limit.patch
  
  These also apply on top of 3.5 (with context reduced to 2 for
  target-fix-reading-of-data-length-fields-for-unmap-commands.patch) and
  build cleanly.
 
 Many thanks, that worked wonderfully.
 

Thanks a bunch to BenH for taking care of these stable 3.2 patches, and
forward porting them 3.4 - 3.5 !

--nab


--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


FAILED: patch [PATCH] target: Add range checking to UNMAP emulation failed to apply to 3.5-stable tree

2012-07-31 Thread gregkh

The patch below does not apply to the 3.5-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to stable@vger.kernel.org.

thanks,

greg k-h

-- original commit in Linus's tree --

From 2594e29865c291db162313187612cd9f14538f33 Mon Sep 17 00:00:00 2001
From: Roland Dreier rol...@purestorage.com
Date: Mon, 16 Jul 2012 15:34:22 -0700
Subject: [PATCH] target: Add range checking to UNMAP emulation

When processing an UNMAP command, we need to make sure that the number
of blocks we're asked to UNMAP does not exceed our reported maximum
number of blocks per UNMAP, and that the range of blocks we're
unmapping doesn't go past the end of the device.

Signed-off-by: Roland Dreier rol...@purestorage.com
Cc: stable@vger.kernel.org
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org

diff --git a/drivers/target/target_core_iblock.c 
b/drivers/target/target_core_iblock.c
index 8a12e29..8fb3822 100644
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -348,6 +348,18 @@ static int iblock_execute_unmap(struct se_cmd *cmd)
pr_debug(UNMAP: Using lba: %llu and range: %u\n,
 (unsigned long long)lba, range);
 
+   if (range  dev-se_sub_dev-se_dev_attrib.max_unmap_lba_count) 
{
+   cmd-scsi_sense_reason = TCM_INVALID_PARAMETER_LIST;
+   ret = -EINVAL;
+   goto err;
+   }
+
+   if (lba + range  dev-transport-get_blocks(dev) + 1) {
+   cmd-scsi_sense_reason = TCM_ADDRESS_OUT_OF_RANGE;
+   ret = -EINVAL;
+   goto err;
+   }
+
ret = blkdev_issue_discard(ibd-ibd_bd, lba, range,
   GFP_KERNEL, 0);
if (ret  0) {

--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: FAILED: patch [PATCH] target: Add range checking to UNMAP emulation failed to apply to 3.5-stable tree

2012-07-31 Thread Ben Hutchings
On Tue, 2012-07-31 at 11:11 -0700, gre...@linuxfoundation.org wrote:
 The patch below does not apply to the 3.5-stable tree.
 If someone wants it applied there, or to any other stable or longterm
 tree, then please email the backport, including the original git commit
 id to stable@vger.kernel.org.
[...]

Here are the versions I applied to 3.2.y, for this and the following 3
target changes.  The ordering is:

target-add-range-checking-to-unmap-emulation.patch
target-fix-reading-of-data-length-fields-for-unmap-commands.patch
target-fix-possible-integer-underflow-in-unmap-emulation.patch
target-check-number-of-unmap-descriptors-against-our-limit.patch

These also apply on top of 3.5 (with context reduced to 2 for
target-fix-reading-of-data-length-fields-for-unmap-commands.patch) and
build cleanly.

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed.
 - Carolyn Scheppner
From: Roland Dreier rol...@purestorage.com
Date: Mon, 16 Jul 2012 15:34:22 -0700
Subject: target: Add range checking to UNMAP emulation

commit 2594e29865c291db162313187612cd9f14538f33 upstream.

When processing an UNMAP command, we need to make sure that the number
of blocks we're asked to UNMAP does not exceed our reported maximum
number of blocks per UNMAP, and that the range of blocks we're
unmapping doesn't go past the end of the device.

Signed-off-by: Roland Dreier rol...@purestorage.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
 drivers/target/target_core_cdb.c |   12 
 1 file changed, 12 insertions(+)

--- a/drivers/target/target_core_cdb.c
+++ b/drivers/target/target_core_cdb.c
@@ -1145,6 +1145,18 @@ int target_emulate_unmap(struct se_task
 		pr_debug(UNMAP: Using lba: %llu and range: %u\n,
  (unsigned long long)lba, range);
 
+		if (range  dev-se_sub_dev-se_dev_attrib.max_unmap_lba_count) {
+			cmd-scsi_sense_reason = TCM_INVALID_PARAMETER_LIST;
+			ret = -EINVAL;
+			goto err;
+		}
+
+		if (lba + range  dev-transport-get_blocks(dev) + 1) {
+			cmd-scsi_sense_reason = TCM_ADDRESS_OUT_OF_RANGE;
+			ret = -EINVAL;
+			goto err;
+		}
+
 		ret = dev-transport-do_discard(dev, lba, range);
 		if (ret  0) {
 			pr_err(blkdev_issue_discard() failed: %d\n,
From: Roland Dreier rol...@purestorage.com
Date: Mon, 16 Jul 2012 15:34:25 -0700
Subject: target: Check number of unmap descriptors against our limit

commit 7409a6657aebf8be74c21d0eded80709b27275cb upstream.

Fail UNMAP commands that have more than our reported limit on unmap
descriptors.

Signed-off-by: Roland Dreier rol...@purestorage.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
 drivers/target/target_core_cdb.c |5 +
 1 file changed, 5 insertions(+)

--- a/drivers/target/target_core_cdb.c
+++ b/drivers/target/target_core_cdb.c
@@ -1133,6 +1133,11 @@ int target_emulate_unmap(struct se_task
 	bd_dl = get_unaligned_be16(buf[2]);
 
 	size = min(size - 8, bd_dl);
+	if (size / 16  dev-se_sub_dev-se_dev_attrib.max_unmap_block_desc_count) {
+		cmd-scsi_sense_reason = TCM_INVALID_PARAMETER_LIST;
+		ret = -EINVAL;
+		goto err;
+	}
 
 	/* First UNMAP block descriptor starts at 8 byte offset */
 	ptr = buf[8];
From: Roland Dreier rol...@purestorage.com
Date: Mon, 16 Jul 2012 15:34:24 -0700
Subject: target: Fix possible integer underflow in UNMAP emulation

commit b7fc7f3777582dea85156a821d78a522a0c083aa upstream.

It's possible for an initiator to send us an UNMAP command with a
descriptor that is less than 8 bytes; in that case it's really bad for
us to set an unsigned int to that value, subtract 8 from it, and then
use that as a limit for our loop (since the value will wrap around to
a huge positive value).

Fix this by making size be signed and only looping if size = 16 (ie
if we have at least a full descriptor available).

Also remove offset as an obfuscated name for the constant 8.

Signed-off-by: Roland Dreier rol...@purestorage.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
 drivers/target/target_core_cdb.c |   20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

--- a/drivers/target/target_core_cdb.c
+++ b/drivers/target/target_core_cdb.c
@@ -1115,9 +1115,10 @@ int target_emulate_unmap(struct se_task
 	struct se_device *dev = cmd-se_dev;
 	unsigned char *buf, *ptr = NULL;
 	sector_t lba;
-	unsigned int size = cmd-data_length, range;
-	int ret = 0, offset;
-	unsigned short dl, bd_dl;
+	int size = cmd-data_length;
+	u32 range;
+	int ret = 0;
+	int dl, bd_dl;
 
 	if (!dev-transport-do_discard) {
 		pr_err(UNMAP emulation not supported for: %s\n,
@@ -1126,20 +1127,19 @@ int target_emulate_unmap(struct se_task