From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Elias Oltmanns <eo@nebensachen.de>
Cc: Alan Stern <stern@rowland.harvard.edu>,
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 08:55:41 -0500 [thread overview]
Message-ID: <1216216541.3230.4.camel@localhost.localdomain> (raw)
In-Reply-To: <87vdz63q1b.fsf@denkblock.local>
On Wed, 2008-07-16 at 15:41 +0200, Elias Oltmanns wrote:
> 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.
I think all you don't understand is simply that for a REQ_BLOCK_PC, the
residue (that's the amount of untransferred, or at least bogus, data) is
returned in req->data_len. Thus, after such a request completes, you
have bufflen-req->data_len good bytes.
James
next prev parent reply other threads:[~2008-07-16 13:55 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
2008-07-16 13:55 ` James Bottomley [this message]
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=1216216541.3230.4.camel@localhost.localdomain \
--to=james.bottomley@hansenpartnership.com \
--cc=bharrosh@panasas.com \
--cc=eo@nebensachen.de \
--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 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.