[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0C18FE92A7765D4EB9EE5D38D86A563A01A34C18@SHSMSX103.ccr.corp.intel.com>
Date: Fri, 3 Jan 2014 01:44:21 +0000
From: "Du, ChangbinX" <changbinx.du@...el.com>
To: Alan Stern <stern@...land.harvard.edu>
CC: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"sarah.a.sharp@...ux.intel.com" <sarah.a.sharp@...ux.intel.com>,
"Lan, Tianyu" <tianyu.lan@...el.com>,
"burzalodowa@...il.com" <burzalodowa@...il.com>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] usb/core: fix NULL pointer dereference in
recursively_mark_NOTATTACHED
> On Thu, 26 Dec 2013, Du, ChangbinX wrote:
>
> > I can reproduce issue by adding a delay just after
> > usb_set_intfdata(intf, NULL) (echo -1 > bConfigurationValue to trigger
> hub_dissconnect())without your patch.
> >
> > After patch applied, cannot reproduce and didn't found any other issue.
> Patch works well.
> >
> > Alan, need I update patch to v2 or you will do it?
>
> Changbin, after looking more closely I realized there was a second aspect to
> this race: recursively_mark_NOTATTACHED uses hub->ports[i] while
> hub_disconnect removes the port devices. You ought to be able to cause
> an oops by inserting a delay just after the loop where
> usb_hub_remove_port_device is called.
>
> The updated patch below should fix both problems. Can you test it?
>
> Alan Stern
>
Ok, I'll test it today or tomorrow. Please wait my response.
--
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/
Powered by blists - more mailing lists