On Wed, Jan 26, 2011 at 11:14:17AM -0800, Alan Stern wrote: > On Wed, 26 Jan 2011, Micah Elizabeth Scott wrote: > > > Hello, > > > > I just filed a bug on kernel.org, and Greg K-H suggested I also > > mention it directly here. It's bug 27612 on kernel.org: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=27612 > > > > This is a fairly minor bug, since as far as I know the only way to > > trigger it is via a buggy or malicious USB hub device. However, in the > > event of a malicious USB device, this bug could be used as a DoS to > > the hub thread, making the USB subsystem somewhat unusable until > > reboot. > > A similar problem will occur if you connect your faulty hub to an EHCI > controller. > > In my opinion, the best way to deal with this is simply to reject > high-speed hubs that don't have any TTs. Presumably there aren't many > devices like that floating around. Do you agree? > > The following patch implements this policy. It should eliminate your > bug. Perhaps this is selfish, but I'd strongly advocate against this patch since it will break all of our virtual hubs here at VMware :) We emulate USB hubs in order to dynamically extend the number of ports available to a virtual machine. We never create hubs with TTs, partly so we can avoid the performance overhead and implementation complexity of them, and partly because we really have no need for them. (We can always have both a high-speed and a full/low-speed hub available, and plug devices into the correct one.) --beth -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
