public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Elias Oltmanns <eo@nebensachen.de>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
	Peter Teoh <htmldeveloper@gmail.com>,
	Maciej Rutecki <maciej.rutecki@gmail.com>,
	Boaz Harrosh <bharrosh@panasas.com>,
	USB Storage list <usb-storage@lists.one-eyed-alien.net>,
	SCSI development list <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] SCSI: erase invalid data returned by device
Date: Wed, 16 Jul 2008 15:41:04 +0200	[thread overview]
Message-ID: <87vdz63q1b.fsf@denkblock.local> (raw)
In-Reply-To: Pine.LNX.4.44L0.0806241402020.2166-100000@iolanthe.rowland.org

Alan Stern <stern@rowland.harvard.edu> wrote:
> This patch (as1108) fixes a problem that can occur with certain USB
> mass-storage devices: They return invalid data together with a residue
> indicating that the data should be ignored.  Rather than leave the
> invalid data in a transfer buffer, where it can get misinterpreted,
> the patch clears the invalid portion of the buffer.

I've only just stumbled upon this patch and I don't quite understand how
it is supposed to work.

>
> This solves a problem (wrong write-protect setting detected) reported
> by Maciej Rutecki and Peter Teoh.
>
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> Tested-by: Peter Teoh <htmldeveloper@gmail.com>
>
> ---
>
> Index: usb-2.6/drivers/scsi/scsi_lib.c
> ===================================================================
> --- usb-2.6.orig/drivers/scsi/scsi_lib.c
> +++ usb-2.6/drivers/scsi/scsi_lib.c
> @@ -207,6 +207,15 @@ int scsi_execute(struct scsi_device *sde
>  	 */
>  	blk_execute_rq(req->q, NULL, req, 1);
>  
> +	/*
> +	 * Some devices (USB mass-storage in particular) may transfer
> +	 * garbage data together with a residue indicating that the data
> +	 * is invalid.  Prevent the garbage from being misinterpreted
> +	 * and prevent security leaks by zeroing out the excess data.
> +	 */
> +	if (unlikely(req->data_len > 0 && req->data_len <= bufflen))
> +		memset(buffer + (bufflen - req->data_len), 0, req->data_len);

Sorry, I don't understand that line at all. Surely, we want to zero out
either the excess data, i.e. buffer -> buffer + req->data_len, or the
residue, i.e. buffer + req->data_len -> buffer + bufflen. Your patch
implies that there are bufflen - req->data_len bytes of valid data at
the beginning of buffer. If this is intentional, please bear with me and
explain. Otherwise, what about the following patch to 2.6.26? On the
other hand, the same could probably be achieved by setting req->data_len
to 0. Oh dear, it would appear that I'm completely lost here.

Elias


diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index cbf55d5..977f22b 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -214,7 +214,7 @@ int scsi_execute(struct scsi_device *sdev, const unsigned char *cmd,
 	 * and prevent security leaks by zeroing out the excess data.
 	 */
 	if (unlikely(req->data_len > 0 && req->data_len <= bufflen))
-		memset(buffer + (bufflen - req->data_len), 0, req->data_len);
+		memset(buffer + req->data_len, 0, bufflen - req->data_len);
 
 	ret = req->errors;
  out:

  parent reply	other threads:[~2008-07-16 13:41 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <48328E81.2080504@panasas.com>
2008-05-20 14:23 ` [Re: Linux 2.6.26-rc2] Write protect on on Alan Stern
2008-06-03 15:02 ` Alan Stern
2008-06-13 16:57   ` Maciej Rutecki
2008-06-13 18:02     ` Alan Stern
2008-06-14  7:02       ` Maciej Rutecki
2008-06-20 20:22         ` Alan Stern
2008-06-20 20:56           ` James Bottomley
2008-06-20 21:46             ` Alan Stern
2008-06-20 22:09               ` James Bottomley
2008-06-21  2:17                 ` Alan Stern
2008-06-23 15:04                 ` Alan Stern
2008-06-24  3:25                   ` Peter Teoh
2008-06-24  4:09                     ` Peter Teoh
2008-06-24 18:03                       ` [PATCH] SCSI: erase invalid data returned by device Alan Stern
2008-07-10 23:15                         ` Cal Peake
2008-07-10 23:23                           ` Linus Torvalds
2008-07-10 23:28                             ` James Bottomley
2008-07-10 23:35                               ` Linus Torvalds
2008-07-16 13:41                         ` Elias Oltmanns [this message]
2008-07-16 13:55                           ` James Bottomley
2008-07-16 14:12                             ` Elias Oltmanns
2008-07-16 14:28                               ` Alan Stern
2008-07-16 14:39                                 ` Elias Oltmanns
2008-07-16 14:01                           ` Boaz Harrosh
2008-06-24 14:59                     ` [Re: Linux 2.6.26-rc2] Write protect on on Alan Stern
2008-06-24 16:59                       ` Maciej Rutecki

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=87vdz63q1b.fsf@denkblock.local \
    --to=eo@nebensachen.de \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=bharrosh@panasas.com \
    --cc=htmldeveloper@gmail.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=maciej.rutecki@gmail.com \
    --cc=stern@rowland.harvard.edu \
    --cc=usb-storage@lists.one-eyed-alien.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox