From: sashiko-bot@kernel.org
To: "Akari Tsuyukusa" <akkun11.open@gmail.com>
Cc: "open list:COMMON CLK FRAMEWORK" <linux-clk@vger.kernel.org>
Subject: Re: [PATCH v2 14/35] clk: mediatek: Add child-device population to probe/remove helpers
Date: Tue, 13 Oct 2026 16:10:54 +0000 [thread overview]
Message-ID: <sashiko-outbox-170095@kernel.org> (raw)
In-Reply-To: <20261013151734.3177690-15-akkun11.open@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] clk: mediatek: NULL deref in __mtk_clk_simple_remove() without id_table fallback
- [High] clk: mediatek: Use-after-free of clk in devm notifier release
--
commit 4b72b775dd71cd9f8aca52f2f386291f6722da4e
Author: Akari Tsuyukusa <akkun11.open@gmail.com>
clk: mediatek: Add child-device population to probe/remove helpers
MediaTek audio clock drivers call devm_of_platform_populate() after
mtk_clk_simple_probe(). Extend __mtk_clk_simple_probe() to run
of_platform_populate() when the new 'populate_children' flag is set,
reducing boilerplate.
> diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
> index e06cd40d995a9..1172e76516c03 100644
> --- a/drivers/clk/mediatek/clk-mtk.c
> +++ b/drivers/clk/mediatek/clk-mtk.c
[ ... ]
> @@ -603,7 +604,16 @@ static int __mtk_clk_simple_probe(struct platform_device *pdev,
> r = mtk_register_reset_controller_with_dev(&pdev->dev,
> mcd->rst_desc);
> if (r)
> - goto unregister_clks;
> + goto unregister_provider;
> + }
> +
> + if (mcd->populate_children) {
> + r = of_platform_populate(pdev->dev.of_node, NULL, NULL,
> + &pdev->dev);
> + if (r) {
> + of_platform_depopulate(&pdev->dev);
> + goto unregister_provider;
[Severity: High]
Does this new error path cause a use-after-free on the clk?
If __mtk_clk_simple_probe() has previously registered a rate-change
notifier on a struct clk using devm_clk_notifier_register() (via
mcd->clk_notifier_func), the notifier's lifetime is tied to the
pdev->dev devres list.
When taking this goto unregister_provider error path, the clocks are
manually unregistered via the cleanup labels, for example by calling
mtk_clk_unregister_muxes() which calls clk_hw_unregister() and then
clk_unregister().
clk_unregister() frees the struct clk pointer, but does not remove its
associated notifiers from clk_notifier_list.
Later, when the driver core invokes devres_release_all() for the device,
it calls devm_clk_notifier_release(), which invokes
clk_notifier_unregister() with the now-freed struct clk pointer, resulting
in a use-after-free.
This use-after-free also appears to occur during driver unbind in
__mtk_clk_simple_remove().
[ ... ]
> @@ -658,6 +671,9 @@ static void __mtk_clk_simple_remove(struct platform_device *pdev,
> struct clk_hw_onecell_data *clk_data = platform_get_drvdata(pdev);
> const struct mtk_clk_desc *mcd = device_get_match_data(&pdev->dev);
>
> + if (mcd->populate_children)
[Severity: High]
Can this dereference a NULL mcd pointer during driver removal?
Many MediaTek clock drivers register as platform drivers using an
id_table without an of_match_table. While __mtk_clk_simple_probe() handles
this by safely falling back to platform_get_device_id() when
device_get_match_data() returns NULL, __mtk_clk_simple_remove() lacks
this fallback.
When the driver is unbound, for instance via sysfs or module unload,
device_get_match_data() will return NULL, causing mcd->populate_children
to crash.
> + of_platform_depopulate(&pdev->dev);
> +
> of_clk_del_provider(node);
> if (mcd->clks)
> mtk_clk_unregister_gates(mcd->clks, mcd->num_clks, clk_data);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261013151734.3177690-1-akkun11.open@gmail.com?part=14
next prev parent reply other threads:[~2026-10-13 16:10 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 15:16 [PATCH v2 00/35] clk: mediatek: Migrate to common probe/remove helpers and fix memory leaks Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 01/35] clk: mediatek: mt2712: Fix memory leak on module removal Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 02/35] clk: mediatek: mt6795: " Akari Tsuyukusa
2026-10-13 15:36 ` sashiko-bot
2026-10-13 15:17 ` [PATCH v2 03/35] clk: mediatek: mt7622: " Akari Tsuyukusa
2026-10-13 15:34 ` sashiko-bot
2026-10-13 15:17 ` [PATCH v2 04/35] clk: mediatek: mt8135: " Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 05/35] clk: mediatek: mt8173: " Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 06/35] clk: mediatek: mt8192: " Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 07/35] clk: mediatek: mt6735: Add missing MODULE_DEVICE_TABLE() Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 08/35] clk: mediatek: mt7988-apmixed: " Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 09/35] clk: mediatek: Fix index in composite clock unwind path Akari Tsuyukusa
2026-10-13 15:49 ` sashiko-bot
2026-10-13 15:17 ` [PATCH v2 10/35] clk: mediatek: Fix memory leak in mtk_clk_register_gate() Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 11/35] clk: mediatek: return 0 instead of r in __mtk_clk_simple_probe() Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 12/35] clk: mediatek: Add cpumux support to common probe/remove helpers Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 13/35] clk: mediatek: Add PLL " Akari Tsuyukusa
2026-10-13 15:58 ` sashiko-bot
2026-10-13 15:17 ` [PATCH v2 14/35] clk: mediatek: Add child-device population to " Akari Tsuyukusa
2026-10-13 16:10 ` sashiko-bot [this message]
2026-10-13 15:17 ` [PATCH v2 15/35] clk: mediatek: Add FHCTL support to common " Akari Tsuyukusa
2026-10-13 16:09 ` sashiko-bot
2026-10-13 15:17 ` [PATCH v2 16/35] clk: mediatek: mt2701: Switch " Akari Tsuyukusa
2026-10-13 16:23 ` sashiko-bot
2026-10-13 15:17 ` [PATCH v2 17/35] clk: mediatek: mt2712-apmixedsys: " Akari Tsuyukusa
2026-10-13 16:20 ` sashiko-bot
2026-10-13 15:17 ` [PATCH v2 18/35] clk: mediatek: mt6735-apmixedsys: " Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 19/35] clk: mediatek: mt6779: " Akari Tsuyukusa
2026-10-13 16:31 ` sashiko-bot
2026-10-13 15:17 ` [PATCH v2 20/35] clk: mediatek: mt6795: " Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 21/35] clk: mediatek: mt6797: " Akari Tsuyukusa
2026-10-13 16:39 ` sashiko-bot
2026-10-13 15:17 ` [PATCH v2 22/35] clk: mediatek: mt7622: " Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 23/35] clk: mediatek: mt7981-apmixed: " Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 24/35] clk: mediatek: mt7986-apmixed: " Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 25/35] clk: mediatek: mt7988-apmixed: " Akari Tsuyukusa
2026-10-13 16:52 ` sashiko-bot
2026-10-13 15:17 ` [PATCH v2 26/35] clk: mediatek: mt8135-apmixedsys: " Akari Tsuyukusa
2026-10-13 16:50 ` sashiko-bot
2026-10-13 15:17 ` [PATCH v2 27/35] clk: mediatek: mt8167-apmixedsys: " Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 28/35] clk: mediatek: mt8173-infracfg: " Akari Tsuyukusa
2026-10-13 17:01 ` sashiko-bot
2026-10-13 15:17 ` [PATCH v2 29/35] clk: mediatek: mt8183: " Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 30/35] clk: mediatek: mt8186-apmixedsys: " Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 31/35] clk: mediatek: mt8188-apmixedsys: " Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 32/35] clk: mediatek: mt8192: " Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 33/35] clk: mediatek: mt8195: " Akari Tsuyukusa
2026-10-13 15:17 ` [PATCH v2 34/35] clk: mediatek: mt8196: " Akari Tsuyukusa
2026-10-13 17:24 ` sashiko-bot
2026-10-13 15:17 ` [PATCH v2 35/35] clk: mediatek: mt8516-apmixedsys: " Akari Tsuyukusa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-170095@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=akkun11.open@gmail.com \
--cc=linux-clk@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox