linux-kernel - Re: [PATCH] rfkill: Fix use-after-free in rfkill

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] [day] [month] [year] [list]

Date:   Thu, 12 Nov 2020 09:17:40 +0100
From:   Johannes Berg <johannes@...solutions.net>
To:     Claire Chang <tientzu@...omium.org>
Cc:     davem@...emloft.net, kuba@...nel.org, hdegoede@...hat.com,
        marcel@...tmann.org,
        "open list:NETWORKING DRIVERS (WIRELESS)" 
        <linux-wireless@...r.kernel.org>, netdev@...r.kernel.org,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] rfkill: Fix use-after-free in rfkill_resume()

On Wed, 2020-11-11 at 11:23 +0800, Claire Chang wrote:
> On Wed, Nov 11, 2020 at 1:35 AM Johannes Berg <johannes@...solutions.net> wrote:
> > On Tue, 2020-11-10 at 16:49 +0800, Claire Chang wrote:
> > > If a device is getting removed or reprobed during resume, use-after-free
> > > might happen. For example, h5_btrtl_resume()[drivers/bluetooth/hci_h5.c]
> > > schedules a work queue for device reprobing. During the reprobing, if
> > > rfkill_set_block() in rfkill_resume() is called after the corresponding
> > > *_unregister() and kfree() are called, there will be an use-after-free
> > > in hci_rfkill_set_block()[net/bluetooth/hci_core.c].
> > 
> > Not sure I understand. So you're saying
> > 
> >  * something (h5_btrtl_resume) schedules a worker
> >  * said worker run, when it runs, calls rfkill_unregister()
> >  * somehow rfkill_resume() still gets called after this
> > 
> > But that can't really be right, device_del() removes it from the PM
> > lists?
> 
> If device_del() is called right before the device_lock() in device_resume()[1],
> it's possible the rfkill device is unregistered, but rfkill_resume is
> still called.

OK, I see, thanks for the clarification!

I'll try to add that to the commit message.

Thanks,
johannes