On Thu, 22 Aug 2019, Alan Stern wrote: > > > > > I've ran the fuzzer with your patches applied overnight and noticed > > > > > another fallout of similar bugs. I think they are caused by a similar > > > > > issue in the sony HID driver. There's no hid_hw_stop() call in the "if > > > > > (!(hdev->claimed & HID_CLAIMED_INPUT))" case in sony_probe(). Does it > > > > > look like a bug to you? > > > > > > > > It looks like the relevant hid_hw_stop() call is the one at the end of > > > > sony_configure_input(). But I can't tell if doing that way is valid or > > > > not -- in practice the code would end up calling hid_disconnect() while > > > > hid_connect() was still running, which doesn't seem like a good idea. > > > > > > > > There's a comment about this near the end of sony_probe(). I suspect > > > > it would be better to call hid_hw_stop() in the conditional code > > > > following that comment rather than in sony_configure_input(). > > > > > > > > Either way, these are all things Jiri should know about or check up on. > > > > > > > > Have you gotten any test results from syzbot exercising these pathways? > > > > You ought to be able to tell which HID driver is involved by looking > > > > through the console output. > > > > > > Yes, a typical crash is below, that's why I thought it's the sony > > > driver. Adding hid_hw_stop() in sony_probe() stops the issue from > > > happening, but I don't know whether it's the right fix. > > > > Probably you have to add hid_hw_stop() in sony_probe() and remove it > > from sony_configure_input(). But like I said above, Jiri should look > > into this. > It almost certainly is, thanks. > Adding Roderick to CC ... Roderick, will you be able to test and submit > a patch fixing that? > > -- > Jiri Kosina > SUSE Labs Sure we will have a look and do some testing. Hopefully we can share a patch some time next week. Thanks, Roderick
