On Sunday 02 May 2010 17:02:22 Alan Stern wrote: > Can you figure out what statement corresponds to the faulting > instruction address, and which pointer is NULL? Let's simply look at the code: The very first dereference made in usb_altnum_to_altsetting() is intf->num_altsetting Which is offset 0x8 (on 32bit). That matches the OOPS. That function is called by usb_reset_configuration, according to the backtrace. There we have a loop which loops through the configs. For each config it retrieves the usb_interface pointer and calls usb_altnum_to_altsetting() on it. So I am pretty certain that the struct usb_interface *intf pointer is NULL here. So why is it NULL? I can't really tell, because I don't know the details of that code. All I can tell is that the device sends _really_ fucked up device and config descriptors to the kernel. So my guess is that some sanity checks on the config and/or device descriptors are missing/needed. The loop uses the hardware descriptor's (untrusted?) bNumInterfaces in the loop termination statement. That rings a bell for me. Note that the kernel also throws this message: [ 245.449456] usb 4-1: too many configurations: 25, using maximum allowed: 8 Is that related? It smells like that to me. What if we only allocated 8 configs earlier but try to loop 25 configs now? -- Greetings, Michael. -- 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
