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]

Message-ID: <20190205081846.GA118684@dtor-ws>
Date:   Tue, 5 Feb 2019 00:18:46 -0800
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Sven Van Asbroeck <thesven73@...il.com>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>
Cc:     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

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.

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?

Thanks.

-- 
Dmitry