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 15/35] clk: mediatek: Add FHCTL support to common probe/remove helpers
Date: Tue, 13 Oct 2026 16:09:00 +0000 [thread overview]
Message-ID: <sashiko-outbox-170092@kernel.org> (raw)
In-Reply-To: <20261013151734.3177690-16-akkun11.open@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] clk: mediatek: Use-After-Free of FHCTL base on probe deferral / rebind
- [Medium] clk: mediatek: memory leak of FHCTL iomem base on probe failure or no matches
--
commit 8d87854263bcfad5cea06d0fd17b75e7b846a747
Author: Akari Tsuyukusa <akkun11.open@gmail.com>
clk: mediatek: Add FHCTL support to common probe/remove helpers
Extend __mtk_clk_simple_probe() and __mtk_clk_simple_remove() to support
FHCTL. This reduces boilerplate code in apmixedsys drivers with FHCTL
support.
> diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
> index 1172e76516c03..8fa81a8671ad0 100644
> --- a/drivers/clk/mediatek/clk-mtk.c
> +++ b/drivers/clk/mediatek/clk-mtk.c
[ ... ]
> @@ -525,8 +529,18 @@ static int __mtk_clk_simple_probe(struct platform_device *pdev,
> }
>
> if (mcd->plls) {
> - r = mtk_clk_register_plls(&pdev->dev, mcd->plls,
> +#if IS_ENABLED(CONFIG_COMMON_CLK_MEDIATEK_FHCTL)
> + if (mcd->fhctl_node) {
> + fhctl_parse_dt(mcd->fhctl_node, mcd->pllfhs,
> + mcd->num_pllfhs);
> + r = mtk_clk_register_pllfhs(&pdev->dev, mcd->plls,
> + mcd->num_plls, mcd->pllfhs,
> + mcd->num_pllfhs, clk_data);
[Severity: Medium]
This problem wasn't introduced by this patch, but does calling
fhctl_parse_dt() here expose drivers to a memory leak of the fhctl iomem
base mapped via of_iomap() in fhctl_parse_dt()?
If mtk_clk_register_pllfhs() fails, the code jumps to the free_data label
in __mtk_clk_simple_probe(), bypassing unregister_plls. As a result, the
mapped i/o memory seems to be permanently leaked.
Additionally, if mtk_clk_register_pllfhs() fails to register the very first
pll, it skips its internal cleanup loop entirely, meaning the memory mapped
by fhctl_parse_dt() is never unmapped.
[Severity: High]
This problem wasn't introduced by this patch, but does the common
registration path expose fhctl-enabled drivers to a use-after-free during
probe deferral or device rebinds?
During a successful call, fhctl_parse_dt() mutates the static mcd->pllfhs
array by setting pllfh->state.fh_enable = 1 and storing the mapped i/o
pointer in pllfh->state.base.
If the probe later fails and the device is removed,
mtk_clk_unregister_pllfhs() calls iounmap() on the base but fails to clear
the fh_enable flag or the stale base pointer from the static array.
If the device is subsequently re-bound and fhctl_parse_dt() fails early
(leaving the static array unmodified), won't mtk_clk_register_pllfhs()
still see fh_enable == 1 from the previous probe and blindly dereference
the stale, unmapped state.base pointer?
> + } else
> +#endif
> + r = mtk_clk_register_plls(&pdev->dev, mcd->plls,
> mcd->num_plls, clk_data);
> +
> if (r)
> goto free_data;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261013151734.3177690-1-akkun11.open@gmail.com?part=15
next prev parent reply other threads:[~2026-10-13 16:09 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
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 [this message]
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-170092@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.