Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 5 Feb 2019 00:18:46 -0800
From:   Dmitry Torokhov <dmitry.torokhov@gmail.com>
To:     Sven Van Asbroeck <thesven73@gmail.com>,
        Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc:     Tejun Heo <tj@kernel.org>, Lai Jiangshan <jiangshanlai@gmail.com>,
        linux-kernel@vger.kernel.org, Sebastian Reichel <sre@kernel.org>,
        Kees Cook <keescook@chromium.org>
Subject: Re: [RFC v1 3/3] cap11xx: fix potential user-after-free on module
 unload
Message-ID: <20190205081846.GA118684@dtor-ws>
References: <20190204220952.30761-1-TheSven73@googlemail.com>
 <20190204220952.30761-4-TheSven73@googlemail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190204220952.30761-4-TheSven73@googlemail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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