linux-kernel - Re: BUG: SCSI: usb storage SDHC card doesn't work in 2.6.27-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 30 Jul 2008 15:58:27 -0600
From:	Pete Zaitcev <zaitcev@...hat.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Douglas Gilbert <dougg@...que.net>,
	Matthew Dharm <mdharm-kernel@...-eyed-alien.net>,
	Matt Frost <artusemrys@...global.net>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	USB Storage list <usb-storage@...ts.one-eyed-alien.net>,
	<linux-kernel@...r.kernel.org>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Matthew Frost <artusemrys@...oo.com>
Subject: Re: BUG: SCSI: usb storage SDHC card doesn't work in 2.6.27-rc1

On Wed, 30 Jul 2008 17:28:49 -0400 (EDT), Alan Stern <stern@...land.harvard.edu> wrote:

> > > +		if (bcs->Status == US_BULK_STAT_OK &&
> > > +				scsi_get_resid(srb) == 0 &&
> > > +					((srb->cmnd[0] == INQUIRY &&
> > > +						transfer_length == 36) ||
> > > +					(srb->cmnd[0] == READ_CAPACITY &&
> > > +						transfer_length == 8))) {
> > > +			us->flags |= US_FL_IGNORE_RESIDUE;
> > 
> > Why do you do this for INQUIRY and READ_CAPACITY only?
> > Why not do it for any command?
> 
> Because those are the only two commands for which I'm reasonably
> certain the device should never return a nonzero residue with Okay
> status.  For other commands there might be a valid positive residue --
> although if there is then the device should also return Check Condition
> status (the spec is unclear on this point).

Perhaps I misunderstand how our SCSI stack works. The code in ub is
simpler, it deals with 3 values at the end of transfer:
  Lasked is how much we asked for
  Lgot   is how much was transferred
  Lresid is the reported residue

So, ub checks if the following is true:
  Lasked = Lgot + Lresid

If device fails this check, you can assume that it's just not set up
to report the residue correctly and so, the danger of valid residue
that you outlined becomes rather academic.

The reason I do it this way is, I've seen a device which reported
a correct residue until the first long read, and then residue was
miscalculated due to a 16-bit wrap (it did transfer right data though).
I think it's one of those which are explicitly blacklisted these
days, but I cannot remember.

-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/