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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 27 Mar 2008 01:07:26 -0400
From:	Brad Sawatzky <brad+kernel@...tter.net>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Oliver Neukum <oliver@...kum.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH] usb-serial: fix regression in Visor/Palm OS module for
	kernels >= 2.6.24

On Wed, 26 Mar 2008, Alan Stern wrote:

> On Wed, 26 Mar 2008, Brad Sawatzky wrote:
> 
> > On Wed, 26 Mar 2008, Oliver Neukum wrote:
> > 
> > > Am Mittwoch, 26. März 2008 03:32:43 schrieb Brad Sawatzky:
> > [ . . . ]
> > > > I suppose it's possible that the kernel is identifying 3 bulk endpoints
> > > > when there should only be 2 and there is some issue with the lower level
> > > > endpoint probe?
> > > 
> > > Send in "lsusb -v". Are you sure all devices have 3 endpoints?
[ . . . ]
> You did not understand Oliver's question.  Yes, your device has 3
> bulk-OUT endpoints (and 2 bulk-IN).  But do you know whether _all_
> Visor/Palm OS devices do?  If they don't, your patch will cause the
> driver to stop working when someone plugs in a device with only 2
> endpoints.

You're absolutely right -- a very legitimate point.

I only have one PalmOS USB device and can only provide data for that unit.
As mentioned in the initial post I think it is very suggestive that there is
a kernel bug report saying that both a Treo90 and a Treo750p that exhibited
identical symptoms.  I'd bet a beer that that the kernel also reports 3
bulk out endpoints for those devices, but I can't prove it.

I'm more concerned that the kernel is creating a bogus 3rd endpoint (for
all devices assigned to the so-called "handspring_device") when it should
not.  Any suggestions on how to check that with my particular unit?

I was hoping that whomever authored the original code (Greg?) might know
where the original num_bulk_out=2 value came from: reverse engineering,
best guess, or honest-to-god documentation from Palm?

FWIW, another option I considered was patching the test added in commit
063a2da8f01806906f7d7b1a1424b9afddebc443 to use '<=' instead of '!=' in the
obvious places.  That is, test if the usb-serial subsystem reports at least
as many endpoints as the device definition "requires" rather than checking
for an exact number.  That behaviour is closer to the pre-2.6.24 code (ie.
no check at all) and might be a better fix (provided this 3rd bulk-out
endpoint I'm seeing is 'real' and not due to a lower-level bug).

-- Brad
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ