linux-kernel - Re: [syzbot] KASAN: use-after-free Read in dev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yhj7FO3hisW9yJRN@rowland.harvard.edu>
Date:   Fri, 25 Feb 2022 10:51:48 -0500
From:   "stern@...land.harvard.edu" <stern@...land.harvard.edu>
To:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Cc:     "Zhang, Qiang1" <qiang1.zhang@...el.com>,
        Tejun Heo <tj@...nel.org>,
        syzbot <syzbot+348b571beb5eeb70a582@...kaller.appspotmail.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "syzkaller-bugs@...glegroups.com" <syzkaller-bugs@...glegroups.com>,
        "balbi@...nel.org" <balbi@...nel.org>
Subject: Re: [syzbot] KASAN: use-after-free Read in dev_uevent

On Fri, Feb 25, 2022 at 09:53:35AM +0100, gregkh@...uxfoundation.org wrote:
> On Thu, Feb 24, 2022 at 09:06:13PM -0500, stern@...land.harvard.edu wrote:
> > On Thu, Feb 24, 2022 at 11:37:39PM +0100, gregkh@...uxfoundation.org wrote:
> > > On Thu, Feb 24, 2022 at 04:23:26PM -0500, stern@...land.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