Bjørn Mork <bjorn@xxxxxxx> writes: > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > >> I suspect that answer is to make usb_wwan_disconnect a .port_remove >> callback instead of a .disconnect callback. By the time the disconnect >> method runs, the ports have been unregistered and are basically gone. > > I have a hard time trying to figure out the logic in usb_wwan. > > There is the usb_wwan_release which is called from destroy_serial, > attempting to access and free driver specific serial_port_data. > > And there is the usb_wwan_disconnect which is called from the USB driver > disconnect, and will attempt to kill a number of urbs stored in the > serial_port_data. > > This seems a bit backwards, and AFAICS both of these must expect to be > called after the port is gone. Should both be merged and converted to a > .port_remove callback? That does seem sanest, given that they operate > on port data. One might have guessed this, but the commit which make these Oopses reliable is 0998d0631 device-core: Ensure drvdata = NULL when no driver is bound I did a bisect between 3.5 and next-20120723, and it pointed out this one without doubt. But I believe it only makes the underlying problem in usb_wwan obvious. The use after free has been there forever, just using a pointer which would happen to be valid most of the time. So I guess that commit really is a very nice fix, flushing out things like this. usb_wwan certainly needs fixing. Bjørn -- 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
