linux-kernel - Re: [RFC v1 3/3] cap11xx: fix potential user-after-free on module unload

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:   Tue, 5 Feb 2019 13:43:51 -0800
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Jacek Anaszewski <jacek.anaszewski@...il.com>
Cc:     Sven Van Asbroeck <thesven73@...il.com>, Tejun Heo <tj@...nel.org>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        linux-kernel@...r.kernel.org, Sebastian Reichel <sre@...nel.org>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [RFC v1 3/3] cap11xx: fix potential user-after-free on module
 unload

On Tue, Feb 05, 2019 at 10:24:47PM +0100, Jacek Anaszewski wrote:
> Hi Dmitry,
> 
> On 2/5/19 9:18 AM, Dmitry Torokhov wrote:
> > Hi Sven,
> > 
> > On Mon, Feb 04, 2019 at 05:09:52PM -0500, Sven Van Asbroeck wrote:
> > > The work which is scheduled by led_classdev->brightness_set() is
> > > potentially left pending or running until after the driver module
> > > is unloaded.
> > > 
> > > Fix by using resource-controlled version of INIT_WORK().
> > 
> > I believe this is wrong way of fixing this. The LED classdev objects are
> > refcounted, and may live beyond the point where we unwibd devm stack,
> > so we are still left with the same use-after-free that we currently
> > have.
> 
> Could you please share what LED classdev objects refcounting
> do you have on mind?

My mind was in a state of confusion when I wrote the above ;)

> 
> > This is a general issue with LED subsystem as it provides no callback
> > for properly tearing down device structures, but I think in this
> > particular case we can simply switch from set_brightness() to
> > set_brightness_blocking() which will use the work item internal to the
> > LED classdev and that one is being shut down properly.
> > 
> > Jacek, does the above sound right?
> 
> Yes, since the introduction of brightness_set_blocking op there is no
> need for out-of-led-core workqueues for deferring brightness setting.
> And we do flush_work() in led_classdev_unregister().

OK, great, I'll write up a patch for cap11xx and others if I find them.

Thanks.

-- 
Dmitry