[lkml]   [2019]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC v1 3/3] cap11xx: fix potential user-after-free on module unload
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?

> 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

 \ /
  Last update: 2019-02-05 22:25    [W:0.068 / U:53.836 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site