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;
Subject: Re: [RFC v1 3/3] cap11xx: fix potential user-after-free on module
 unload
To:     Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        Sven Van Asbroeck <thesven73@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>
References: <20190204220952.30761-1-TheSven73@googlemail.com>
 <20190204220952.30761-4-TheSven73@googlemail.com>
 <20190205081846.GA118684@dtor-ws>
From:   Jacek Anaszewski <jacek.anaszewski@gmail.com>
Message-ID: <6565ec19-b629-c289-2fed-a5f404763b74@gmail.com>
Date:   Tue, 5 Feb 2019 22:24:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <20190205081846.GA118684@dtor-ws>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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