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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 24 Feb 2022 21:06:13 -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 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?.  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