On Fri, Jan 04, 2002, Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 04, 2002 at 03:31:12PM +0100, Peter Osterlund wrote:
> > I think my device rapidly disappeared/reappeared and disappeared again
> > on the bus, but I don't know for sure, because I didn't have serial
> > console logging active at the time, and I can not repeat the problem.
> >
> > Anyway, if (header->bLength < 2) is true in usb_parse_interface (line
> > 1546), the endpoint, extra and extralen fields will never be
> > initialized. This will lead to either corruption or a memory leak when
> > usb_destroy_configuration is called. Therefore I think this patch is
> > correct.
>
> Good catch. How about this patch instead which removes a bit of the
> same logic elsewhere:
>
> diff -Nru a/drivers/usb/usb.c b/drivers/usb/usb.c
> --- a/drivers/usb/usb.c Fri Jan 4 13:05:08 2002
> +++ b/drivers/usb/usb.c Fri Jan 4 13:05:08 2002
> @@ -1535,6 +1535,9 @@
> }
>
> ifp = interface->altsetting + interface->num_altsetting;
> + ifp->endpoint = NULL;
> + ifp->extra = NULL;
> + ifp->extralen = 0;
> interface->num_altsetting++;
>
> memcpy(ifp, buffer, USB_DT_INTERFACE_SIZE);
> @@ -1576,10 +1579,7 @@
> /* Copy any unknown descriptors into a storage area for */
> /* drivers to later parse */
> len = (int)(buffer - begin);
> - if (!len) {
> - ifp->extra = NULL;
> - ifp->extralen = 0;
> - } else {
> + if (len) {
> ifp->extra = kmalloc(len, GFP_KERNEL);
>
> if (!ifp->extra) {
While the patch is good for the header->bLength case, I don't think
this is what is causing the problem.
All connects and disconnects are serialized through khubd. There's no
way we could call usb_destroy_configuration when we're in
usb_parse_interface.
Also, if header->bLength is < 2, then we'll almost always get an oops,
not just if the device disappears quickly.
JE
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
