lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 19 Jun 2023 17:38:58 +0800
From:   Fei Shao <fshao@...omium.org>
To:     Dan Carpenter <dan.carpenter@...aro.org>
Cc:     Stephen Boyd <sboyd@...nel.org>,
        Jerome Brunet <jbrunet@...libre.com>,
        Michael Turquette <mturquette@...libre.com>,
        linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] clk: Fix memory leak in devm_clk_notifier_register()

On Mon, Jun 19, 2023 at 5:24 PM Dan Carpenter <dan.carpenter@...aro.org> wrote:
>
> On Mon, Jun 19, 2023 at 05:05:47PM +0800, Fei Shao wrote:
> > On Mon, Jun 19, 2023 at 4:48 PM Dan Carpenter <dan.carpenter@...aro.org> wrote:
> > >
> > > On Mon, Jun 19, 2023 at 11:22:53AM +0800, Fei Shao wrote:
> > > > devm_clk_notifier_register() allocates a devres resource for clk
> > > > notifier but didn't register that to the device, so the notifier didn't
> > > > get unregistered on device detach and the allocated resource was leaked.
> > > >
> > > > Fix the issue by registering the resource through devres_add().
> > > >
> > > > Fixes: 6d30d50d037d ("clk: add devm variant of clk_notifier_register")
> > > > Signed-off-by: Fei Shao <fshao@...omium.org>
> > > > ---
> > > >
> > >
> > > Reviewed-by: Dan Carpenter <dan.carpenter@...aro.org>
> > >
> > > How did you find this bug?
> > >
> > > I can think of some ways to find this bug with static analysis.
> > >
> >
> > It was actually detected by kmemleak on an unreleased Chromebook device.
> > I added the trace snippet in the message at first but removed that
> > before sending this. Maybe I shouldn't have.
> >
> > I can resend a v3 to add that back if that's preferable. What do you think?
>
> I'm not a clk maintainer, but let's not go overboard resending patches,
> especially when they're as straight forward as this one.
>
> This is good information though so I would include that kind of stuff in
> future patches.  I don't really need to see the kmemleak warning itself
> because I know what those look like already.  But to me it says a lot
> that actually this was detected at runtime.  It says good things about
> your test infrastructure and makes me feel more confident that your
> patch is correct.  So maybe just a comment that "This leak was detected
> by kmemleak".

That makes sense. Acknowledged and noted.

Thanks,
Fei

>
> regards,
> dan carpenter
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ