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]

Date:   Sat, 26 Feb 2022 10:07:02 +0100
From:   "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
To:     "stern@...land.harvard.edu" <stern@...land.harvard.edu>
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 10:51:48AM -0500, stern@...land.harvard.edu wrote:
> 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.

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.

thanks,

greg k-h