Messages in this thread | | | Subject | Re: KASAN: use-after-free Read in device_release_driver_internal | From | Oliver Neukum <> | Date | Tue, 06 Aug 2019 16:25:58 +0200 |
| |
Am Dienstag, den 06.08.2019, 10:19 -0400 schrieb Alan Stern: > On Tue, 6 Aug 2019, Oliver Neukum wrote: > > > Am Donnerstag, den 01.08.2019, 14:47 -0400 schrieb Alan Stern: > > > > > > I think this must be caused by an unbalanced refcount. That is, > > > something must drop one more reference to the device than it takes. > > > That would explain why the invalid access occurs inside a single > > > bus_remove_device() call, between the klist_del() and > > > device_release_driver(). > > > > > > The kernel log indicates that the device was probed by rndis_wlan, > > > rndis_host, and cdc_acm, all of which got errors because of the > > > device's bogus descriptors. Probably one of them is messing up the > > > refcount. > > > > Hi, > > > > you made me look at cdc-acm. I suspect > > > > cae2bc768d176bfbdad7035bbcc3cdc973eb7984 ("usb: cdc-acm: Decrement tty port's refcount if probe() fail") > > > > is buggy decrementing the refcount on the interface in destroy() > > even before the refcount is increased. > > > > Unfortunately I cannot tell from the bug report how many and which > > interfaces the emulated test device has. Hence it is unclear to me, > > when exactly probe() would fail cdc-acm. > > Only one interface (numbered 234!).
Yes. cdc-acm went into the look_for_collapsed_interface code path. But I cannot tell whether it proceeded to made_compressed_probe
(Yes, I know the code makes extensive use of "goto")
> > If you agree. I am attaching a putative fix. > > Your patch adds a line saying: > > > + usb_get_intf(acm->control); /* undone in destroy() */ > > but I don't see any destroy() function in that source file. Did you > mean acm_port_destruct()?
Yes, sorry
> In any case, I don't know if this missing "get" would cause the > problem, but it might well.
Then let's wait for the result.
Regards Oliver
| |