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

From: Jacek Anaszewski
Date: Tue Feb 05 2019 - 16:24:55 EST

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

Could you please share what LED classdev objects refcounting
do you have on mind?

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().

Best regards,
Jacek Anaszewski