Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp546076pxm; Fri, 25 Feb 2022 13:25:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJyXPbefUNNDdqRdql6u15LmqYu5sTNQzspuXnfiMh6CGYnpqLyP0BOV0T51fNRtxvqVwJff X-Received: by 2002:a17:906:9947:b0:6cf:e903:fb75 with SMTP id zm7-20020a170906994700b006cfe903fb75mr7336618ejb.400.1645824341994; Fri, 25 Feb 2022 13:25:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645824341; cv=none; d=google.com; s=arc-20160816; b=XL69qzaaLw9Q5KNg/4pGRIH4KjesGyHAHVesbCbDRdTue0kHi4zQt73uSnjwIYZcoz iARyn/XBhKGM4dv1qL6/MW/r+uFk2FTX+39yt/cmlpTdlu/WaT4I5z67bpaKy36feJHo R0sjngC4iGBSqWn0jM2RafLrPOQQCoJW16vUKZdMcPuE3GYxXqm0pGIO4xjLU4+mN9fp QkOqh6vkvPtLBHcAp2yRJiWIHS82yljhSYdHqEYe4VjryZyz2NgvQxXztck4v69Cw1y9 YGiyWX9Axbdsb3pni+YMXCLYqP50LGa59/NiM2/Gnxt9uy/Qa/zzioCl8Y2+gU+DN662 G21w== 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=HPC/Ojpi0VNCdQK86suXeh2Y+SDUhF5HyFm+2vqFRD8=; b=YSEV15BYQCz9vXzfgkDZbZSp1RthBDDtWsQSjpQiN7P2PxXT5esy0Juf5+drZtJQlp X6wrf2rpOof45X3R7fKcuyWFtA4mYGbNIPxysb1n8vIGxiBpJBl6WVZYWgM7aD+OZcwK sllDoh9DYMDBHOkyXdUzB+yHcLuxKXKTEuGpo26a4Rp29A+sJBsrjvT9FPyjIOWmAdY+ DK/s9XR5+vOXaV18QJcZLIvVPO0tkw8S2QkBM244NM7g4/Vj2ecxi8T4t7h4s788XtqS C/D5MPuAF/JONmxAmvK4zR9pI+qto5itVKx/HwJ2MB5d9CD6tmLT82jzRQHgL8glX9/e 6DAw== 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:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x9-20020a170906b08900b006d17526ee9asi2092867ejy.381.2022.02.25.13.25.19; Fri, 25 Feb 2022 13:25:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242357AbiBYPw0 (ORCPT + 99 others); Fri, 25 Feb 2022 10:52:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59306 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232662AbiBYPwW (ORCPT ); Fri, 25 Feb 2022 10:52:22 -0500 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id 718371CF084 for ; Fri, 25 Feb 2022 07:51:49 -0800 (PST) Received: (qmail 1082425 invoked by uid 1000); 25 Feb 2022 10:51:48 -0500 Date: Fri, 25 Feb 2022 10:51:48 -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.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,SPF_HELO_PASS,SPF_PASS, 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 Fri, Feb 25, 2022 at 09:53:35AM +0100, gregkh@linuxfoundation.org wrote: > On Thu, Feb 24, 2022 at 09:06:13PM -0500, stern@rowland.harvard.edu wrote: > > 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?. > > Yes. Or you can use the aux bus for this, which might be easier. > > > 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. > > 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. 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. Alan Stern