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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 086C4C433F5 for ; Fri, 25 Feb 2022 02:06:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236604AbiBYCGq (ORCPT ); Thu, 24 Feb 2022 21:06:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51682 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233794AbiBYCGp (ORCPT ); Thu, 24 Feb 2022 21:06:45 -0500 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id 4CFAC1D6F59 for ; Thu, 24 Feb 2022 18:06:14 -0800 (PST) Received: (qmail 1066190 invoked by uid 1000); 24 Feb 2022 21:06:13 -0500 Date: Thu, 24 Feb 2022 21:06:13 -0500 From: "stern@rowland.harvard.edu" To: "gregkh@linuxfoundation.org" Cc: "Zhang, Qiang1" , Tejun Heo , syzbot , "linux-kernel@vger.kernel.org" , "syzkaller-bugs@googlegroups.com" , "balbi@kernel.org" Subject: Re: [syzbot] KASAN: use-after-free Read in dev_uevent Message-ID: References: <00000000000033314805d8765175@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 24, 2022 at 11:37:39PM +0100, gregkh@linuxfoundation.org wrote: > On Thu, Feb 24, 2022 at 04:23:26PM -0500, stern@rowland.harvard.edu wrote: > > Can you tell us how this should be fixed? > > It should be fixed by properly using the driver core to bind/unbind the > driver to devices like I mentioned previously :) This would involve creating a "gadget" bus_type (or should it be a device_type under the platform bus?) and registering the gadgets on it, right?. Similarly, the gadget drivers would be registered on this bus. I suppose we can control which drivers get bound to which gadgets with careful matching code. > That will be more work, but it's the correct fix here. Otherwise it > needs to take the same bus locks that the device lives on to keep things > in sync, like the driver core would do if it were managing these things. > That could be the "short term" fix if no one wants to do the real work > needed here. Nothing should be needed to change in the driver core > itself, it is rightfully thinking it owns the device and can free it > when needed. All right, thanks. I'll think about implementing it. Alan Stern