From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55CA0C433FF for ; Fri, 9 Aug 2019 12:55:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 27F7B21743 for ; Fri, 9 Aug 2019 12:55:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565355302; bh=wVSbwdE+QsZ0ywu7/8DSOEeXkcgMi1ZNqvYyvYvUp+k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=ZsWtf+JW7YgClovdfHXoIf7Z5jM7GGI10NnSCjfNJMAlPEnypBvsd6rpOQGVkH7mm ZwMO1CC5Q2E1GqD7PwVhI6bUthRGw8gSIbzLdbNus2eAYldKavRoXWOTRFvBGOh8Yi u9V66iFXjlJiEUd0HKZmCqdzxQzlHmV+4DLIV6I4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406802AbfHIMzB (ORCPT ); Fri, 9 Aug 2019 08:55:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:41846 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726505AbfHIMzB (ORCPT ); Fri, 9 Aug 2019 08:55:01 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F1B3020B7C; Fri, 9 Aug 2019 12:54:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565355300; bh=wVSbwdE+QsZ0ywu7/8DSOEeXkcgMi1ZNqvYyvYvUp+k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LYSNhUqbWasx46Kx6lvS5JL7Ayu3tg/3bjgtvvGdTrPshtMjmnmXkdY4xve9E48Is 2q3B6MsLvZOAVNVxJS6vjyGs2pjJWbfdL5x/l7tx71A4TaI6cPAbpXdFtF7deFXBh+ 8+oEK7e1aFFGcgmBX9wmv7z11cM8tJuM6124OBo4= Date: Fri, 9 Aug 2019 14:54:58 +0200 From: Greg KH To: "Schmid, Carsten" Cc: Hans de Goede , Alan Stern , Andrey Konovalov , Oliver Neukum , syzkaller-bugs , syzbot , USB list , Hillf Danton Subject: Re: AW: AW: KASAN: use-after-free Read in usbhid_power Message-ID: <20190809125458.GA2230@kroah.com> References: <20190809075555.GA20409@kroah.com> <8e43085507b849e49e858e5388f3e13c@SVR-IES-MBX-03.mgc.mentorg.com> <86ef050c477841a6951fd984b38c9f04@SVR-IES-MBX-03.mgc.mentorg.com> <9c955960-8b50-30dd-732a-92c62e5761cc@redhat.com> <932dbc769a80416eb736e6397c126ce9@SVR-IES-MBX-03.mgc.mentorg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <932dbc769a80416eb736e6397c126ce9@SVR-IES-MBX-03.mgc.mentorg.com> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org On Fri, Aug 09, 2019 at 12:38:35PM +0000, Schmid, Carsten wrote: > Hi again, > > >> > >> Hey, i did not want to trigger an eartquake in the basement of the kernel ;-) > >> My intention was to prevent some crashes, and help developers to find their bugs. > >> I think my patch exactly does this. > > > > Hehe, actually drivers not being able to block unbind has been bugging me > > for > > a while now, because there are cases where this would be really helpful. > >>> 1) make resources refcounted, have child resources take a ref on the parent > >>> 2) Disallow unbind on devices with bound child-devices? > >>> > >> Exactly what i was thinking of in first attempts. > >> But i fear that would break even more use cases. > >> > >> Hans, directly regarding the driver: > >> The problem i see is that the xhci_intel_unregister_pdev which is added > >> as an action with devm_add_action_or_reset() is called late by the framework, > >> later than the usb_hcd_pci_remove() in xhci_pci_remove. > >> Is there any chance to trigger this before? > >> This is what Greg meant with "right order". > > > > Ah, I missed that part, sure that should be easy, just stop using > > devm_add_action_or_reset() and do the xhci_intel_unregister_pdev() > > manually at the right time. The downside of this is that you also > > need to make sure it happens at the right time from probe error-paths > > but given the bug you are hitting, I guess that is probably > > already a problem. > > > @Hans: > Sure, will have a look at this. I think i have found where to do that, > but need to check how to get the pdev pointer there .... > > @Greg: > I am still confident that my patch in __release_region should be taken in. Ok, submit it in a "real" way and we can consider it :) thanks, greg k-h