linux-kernel - Re: [PATCH v2] clk: Fix memory leak in devm_clk_notifier

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]

Message-ID: <CAC=S1njbLadG+JP38pOrek8RFHYC+En_YXDPaYEbErn8OxFH7g@mail.gmail.com>
Date:   Mon, 19 Jun 2023 18:34:11 +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,
        Markus Elfring <Markus.Elfring@....de>
Subject: Re: [PATCH v2] clk: Fix memory leak in devm_clk_notifier_register()

On Mon, Jun 19, 2023 at 5:57 PM Dan Carpenter <dan.carpenter@...aro.org> wrote:
> The other reason to include stack traces is so that if someone else
> runs into the same bug they can find your patch by googling their stack
> trace.
>
> Normal users aren't going to be running kmemleak.  And people doing
> testing work for companies are hopefully going to pull this fix in via
> the stable tree so they'll get this patch automatically that way so
> they won't see it either.
>
> But if the stack trace is like a NULL dereference bug, then users
> absolutely do notice that kind of thing.  You should always include
> those kind of stack traces.

If that's the case, I can leave a retrospective trace record here:

unreferenced object 0xffffff80c4e34a00 (size 256):
  comm "swapper/0", pid 1, jiffies 4294667967 (age 288.740s)
  hex dump (first 32 bytes):
    00 4a e3 c4 80 ff ff ff 00 4a e3 c4 80 ff ff ff  .J.......J......
    1c 2a 7a ae d8 ff ff ff a0 b0 af af d8 ff ff ff  .*z.............
  backtrace:
    [<000000007d72e65c>] __kmem_cache_alloc_node+0x198/0x240
    [<00000000dfce47ef>] __kmalloc_node_track_caller+0x6c/0x1b8
    [<00000000b6c409fe>] __devres_alloc_node+0x60/0x104
    [<0000000081112baf>] devm_clk_notifier_register+0x44/0xc8
    [<0000000070bfe318>] devm_mtk_clk_mux_notifier_register+0x60/0x74
    [<000000000242235f>] clk_mt8188_reg_mfg_mux_notifier+0x84/0xb4
    [<00000000f67ce424>] clk_mt8188_topck_probe+0x1b8/0x2e4
    [<0000000006eef8cd>] platform_probe+0x12c/0x17c
    [<00000000eacf783c>] really_probe+0x1f0/0x4d8
    [<00000000f321a3f0>] __driver_probe_device+0x160/0x230
    [<00000000bbeed898>] driver_probe_device+0x6c/0x148
    [<000000007d5af62b>] __driver_attach+0x164/0x20c
    [<00000000c5c25e77>] bus_for_each_dev+0xf4/0x144
    [<00000000e2c0100f>] driver_attach+0x50/0x60
    [<00000000cc421ec0>] bus_add_driver+0x2a8/0x458
    [<000000007814168a>] driver_register+0x16c/0x29c

It's up to the maintainers for the next step and I'll follow the call.

Regards,
Fei