Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp303020pxm; Wed, 2 Mar 2022 15:53:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJzpT8B1VVHdWaXsczwQS5xSL8hEmD4ta0FPwg7oZXhd/prYFcj5w9kV2s8SBSEhJcUeM1eh X-Received: by 2002:a63:8bc4:0:b0:341:760f:44d8 with SMTP id j187-20020a638bc4000000b00341760f44d8mr28086902pge.32.1646265211239; Wed, 02 Mar 2022 15:53:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646265211; cv=none; d=google.com; s=arc-20160816; b=AQ2G4Ey8blh5OPhJlRbspr2XZofgR90pyxRx5FtvJOJemDEqxsCa7OoOH8TxAlAk+M M7HdcF3GdkSDAUqLSOFPnmGYa77UXZh/LEdVcmMopVRZQhaX/6HnyvsYu4YtNX7oVT71 +2pGxVYxCQQwQ1cdW2Ybm5AQinfYHAaXnjKCiBW89xMRxka1PThVU79BMfpQ/x7Qd2a9 MIDiqMN6tyDHRk7AHBxWsFJcGvQr27ly+l4FQs8iu0bO4yxf06rifIflEtiSD+fdD/cC 23J6bjRtTcJpS/Zq7Y7ix/ElINGll7HWPFftMAHkQAUm/ghGvgwpwluvRFnZLubcrmun IS6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=PfdZfW4sRLp47fFt66K0R18jKTZrDAeiGuJxec9Zrm8=; b=SgdLXC2g5b5yW6HfCDMoTZYD//xjBGoBlF5uSS7uDPVghdZEWG8SnqGMJgUsbcMr9E hURQzYKMmKebxvdC6TqB/rv86ZUYXf+joY4D9ZYiH27Fu4IRX109Ijf3KwYeA+2gZV3l UDZuImtJXJ+oUA4u79OJjG2zvD1vD5YP7wLb0yHQKdJec0UFqAXHFL//8Q702hg82dWx eiusWivLLfzRJe6OwSfPNItfpmrAOCVIitEeGG2qrGk7x42TQ+Rv9ic7ovro55XHmWvR +4/9i297gZFtjU3RNzLKpR9iIZiQu1+fARXQpgEeYvqFifrumHZwfq/aNrWeRf8t8kCB ZzFg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id a10-20020a1709027d8a00b0014ca108b848si443437plm.102.2022.03.02.15.53.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Mar 2022 15:53:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D3B77181E57; Wed, 2 Mar 2022 15:14:39 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244925AbiCBTLF (ORCPT + 99 others); Wed, 2 Mar 2022 14:11:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55340 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244926AbiCBTLA (ORCPT ); Wed, 2 Mar 2022 14:11:00 -0500 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id 6520BCA707 for ; Wed, 2 Mar 2022 11:10:16 -0800 (PST) Received: (qmail 1244449 invoked by uid 1000); 2 Mar 2022 14:10:15 -0500 Date: Wed, 2 Mar 2022 14:10:15 -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: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Feb 26, 2022 at 10:07:02AM +0100, gregkh@linuxfoundation.org wrote: > On Fri, Feb 25, 2022 at 10:51:48AM -0500, stern@rowland.harvard.edu wrote: > > On Fri, Feb 25, 2022 at 09:53:35AM +0100, gregkh@linuxfoundation.org wrote: > > > The aux bus might make this easier: > > > Documentation/driver-api/auxiliary_bus.rst > > > > Won't this end up changing the user-visible filenames and directories in > > sysfs for gadgets and gadget drivers? > > > > For instance, currently gadgets get registered under their UDC driver > > name, like "net2280" or "at91". If we put them on the aux bus then they > > will have to get registered under a name looking something like > > "udc.gadget.0", i.e., module name, generic device name, and ID number. > > Ah, yeah, that isn't good. > > > We will be forced to use a generic device name because the aux bus does > > matching based on it, and we want every gadget driver to be able to > > match every UDC. We don't want some gadget drivers restricted to > > net2280 gadgets, others restricted to fotg210 gadgets, and so on. > > So yes, I guess it does need to be a "real" bus, sorry. It turns out not to be so bad. In fact there are only five gadget drivers (that is, instances of struct usb_gadget_driver) in the kernel: composite_driver_template (gadget/composite.c) configfs_driver_template (gadget/configfs.c) gadgetfs_driver (gadget/legacy/inode.c) driver (gadget/legacy/raw_gadget.c) dbgp_driver (gadget/legacy/dbgp.c) Everything else is implemented as a "function" driver. So the gadget driver's name doesn't mean very much to the user anyway. The interaction between the gadget subsystem and the device core is rather peculiar. Each UDC controller is represented by a pair of device structures: the .dev fields in struct usb_udc and struct usb_gadget. These two are siblings -- they always have the same parent (see usb_add_gadget() in gadget/udc/core.c). Furthermore, they have the same driver; that is, udc->dev.driver is always the same as gadget->dev.driver (see udc_bind_to_driver()). Which is doubly odd, because gadget drivers manage only gadget devices, not udc devices. The major difference between them is that the usb_udc is a class device whereas the usb_gadget is a "real" device. Currently neither the udc device nor the gadget device is registered on any bus. IMO it would make sense to leave udc->dev.driver always set to NULL, keep the udc devices bus-less, and put the gadget devices on the aux bus. Does that sound reasonable? I'll work on a patch to do it. Alan Stern