[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190205172154.j4zhucvnc7enadbc@earth.universe>
Date: Tue, 5 Feb 2019 18:21:54 +0100
From: Sebastian Reichel <sre@...nel.org>
To: Sven Van Asbroeck <thesven73@...il.com>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Tejun Heo <tj@...nel.org>,
Lai Jiangshan <jiangshanlai@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Kees Cook <keescook@...omium.org>
Subject: Re: [RFC v1 2/3] max17042_battery: fix potential user-after-free on
module unload
Hi,
On Tue, Feb 05, 2019 at 09:27:49AM -0500, Sven Van Asbroeck wrote:
> On Tue, Feb 5, 2019 at 3:27 AM Dmitry Torokhov
> <dmitry.torokhov@...il.com> wrote:
> >
> > Are there many more instances of this?
>
> Unfortunately I think so.
> A simple grep brings up a couple of candidates, but I'm sure there are more:
>
> drivers/regulator/arizona-micsupp.c
> drivers/nfc/port100.c
> drivers/power/supply/max14656_charger_detector.c
> drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
>
> > I am unsure if we need
> > devm_init_work() when we can easily do the same in remove() call.
>
> The devm_init_work() suggestion only addresses the problem for those modules
> that use devm_. The others will need fixes in remove(). But this is not as
> elegant and error-proof as using devm_init_work().
>
> [...]
I would for sure appreciate a devm_init_work(). There are a lot of
devm_ users in power-supply and this helper would definitely
simplify things.
-- Sebastian
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists