linux-kernel - Re: libusb broken on 2.6.28 x86

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] [day] [month] [year] [list]

Message-ID: <495E366C.9050309@rtr.ca>
Date:	Fri, 02 Jan 2009 10:44:44 -0500
From:	Mark Lord <lkml@....ca>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Jan Scholz <scholz@...s.uni-frankfurt.de>,
	Greg KH <gregkh@...e.de>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	USB list <linux-usb@...r.kernel.org>
Subject: Re: libusb broken on 2.6.28 x86_64 ?

Alan Stern wrote:
> On Fri, 2 Jan 2009, Mark Lord wrote:
..
>> This patch, below, FIXES it for me, by undoing a change from 2.6.28.
>>
>> Signed-off-by: Mark Lord <mlord@...ox.com>
>>
>> --- old/drivers/usb/core/driver.c	2008-12-24 18:26:37.000000000 -0500
>> +++ linux/drivers/usb/core/driver.c	2009-01-02 04:34:11.000000000 -0500
>> @@ -279,9 +279,7 @@
>>  	 * altsetting means creating new endpoint device entries).
>>  	 * When either of these happens, defer the Set-Interface.
>>  	 */
>> -	if (intf->cur_altsetting->desc.bAlternateSetting == 0)
>> -		;	/* Already in altsetting 0 so skip Set-Interface */
>> -	else if (!error && intf->dev.power.status == DPM_ON)
>> +	if (!error && intf->dev.power.status == DPM_ON)
>>  		usb_set_interface(udev, intf->altsetting[0].
>>  				desc.bInterfaceNumber, 0);
>>  	else
> 
> For a proper fix, see
> 
> 	http://bugzilla.kernel.org/show_bug.cgi?id=12301#c13
> 
> A corresponding patch has been posted to linux-usb here:
> 
> 	http://marc.info/?l=linux-usb&m=123074111001861&w=2
..

Mmm.. too bad linux-kernel wasn't CC'd on that, or I might have
found the patch and saved some sleep.  Good to see that it has
been fixed down in a subsystem tree, though.

> I have no idea what's going on with the 64-bit vs. 32-bit stuff, though.
..

Yeah, something is very broken somewhere, because the _compat ioctl()s
should really produce the same behaviour as the 64-bit ones.

Looking forward to seeing this regression fixed in mainline ASAP.

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