* [PATCH] rtc: ma35d1: fix permanent clock reference/enable-count leak in probe
@ 2026-09-14 13:18 Cong Nguyen
2026-09-14 13:35 ` sashiko-bot
2026-09-15 6:08 ` Jacky Huang
0 siblings, 2 replies; 3+ messages in thread
From: Cong Nguyen @ 2026-09-14 13:18 UTC (permalink / raw)
To: Jacky Huang
Cc: Shan-Chun Hung, Alexandre Belloni, linux-arm-kernel, linux-rtc,
linux-kernel
ma35d1_rtc_probe() gets the RTC clock via of_clk_get() and enables it
via clk_prepare_enable(), but the struct clk * is a local variable --
never stored anywhere, and the driver has no .remove. So on every
probe, success or failure, there's no way to ever call
clk_disable_unprepare()/clk_put() on it -- a permanent leak, and since
CONFIG_RTC_DRV_MA35D1 is tristate, each module load/unload leaks
another one.
Replace of_clk_get() + clk_prepare_enable() with
devm_clk_get_enabled() -- same clock (both route through
__of_clk_get(np, 0, ...)) but devm-managed, so it's released
automatically on unbind or any probe-failure return.
Fixes: dc0684adf3b6 ("rtc: Add driver for Nuvoton ma35d1 rtc controller")
Assisted-by: Claude:claude-opus-4
Signed-off-by: Cong Nguyen <congnt264@gmail.com>
---
drivers/rtc/rtc-ma35d1.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-ma35d1.c b/drivers/rtc/rtc-ma35d1.c
index cfcfc28060f6..43358d68565a 100644
--- a/drivers/rtc/rtc-ma35d1.c
+++ b/drivers/rtc/rtc-ma35d1.c
@@ -221,14 +221,10 @@ static int ma35d1_rtc_probe(struct platform_device *pdev)
if (IS_ERR(rtc->rtc_reg))
return PTR_ERR(rtc->rtc_reg);
- clk = of_clk_get(pdev->dev.of_node, 0);
+ clk = devm_clk_get_enabled(&pdev->dev, NULL);
if (IS_ERR(clk))
return dev_err_probe(&pdev->dev, PTR_ERR(clk), "failed to find rtc clock\n");
- ret = clk_prepare_enable(clk);
- if (ret)
- return ret;
-
if (!(rtc_reg_read(rtc, MA35_REG_RTC_INIT) & RTC_INIT_ACTIVE)) {
ret = ma35d1_rtc_init(rtc, RTC_INIT_TIMEOUT);
if (ret)
--
2.25.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] rtc: ma35d1: fix permanent clock reference/enable-count leak in probe
2026-09-14 13:18 [PATCH] rtc: ma35d1: fix permanent clock reference/enable-count leak in probe Cong Nguyen
@ 2026-09-14 13:35 ` sashiko-bot
2026-09-15 6:08 ` Jacky Huang
1 sibling, 0 replies; 3+ messages in thread
From: sashiko-bot @ 2026-09-14 13:35 UTC (permalink / raw)
To: Cong Nguyen; +Cc: Alexandre Belloni, linux-rtc
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing check for negative error codes from platform_get_irq(), which converts -EPROBE_DEFER to a permanent -EINVAL failure.
- [High] The RTC device structure can be freed before the IRQ is disabled during unbind or probe failure, leading to a Use-After-Free in the interrupt handler.
--
commit 8480cafa58acd05a264e714619a1853c7065e8bb
Author: Cong Nguyen <congnt264@gmail.com>
rtc: ma35d1: fix permanent clock reference/enable-count leak in probe
This commit fixes a clock reference and enable-count leak in
ma35d1_rtc_probe(). It replaces the manual of_clk_get() and
clk_prepare_enable() sequence with devm_clk_get_enabled(), ensuring the
clock is properly released on probe failure or unbind.
> diff --git a/drivers/rtc/rtc-ma35d1.c b/drivers/rtc/rtc-ma35d1.c
> index cfcfc28060f62..43358d68565a4 100644
> --- a/drivers/rtc/rtc-ma35d1.c
> +++ b/drivers/rtc/rtc-ma35d1.c
> @@ -221,14 +221,10 @@ static int ma35d1_rtc_probe(struct platform_device *pdev)
[ ... ]
> - clk = of_clk_get(pdev->dev.of_node, 0);
> + clk = devm_clk_get_enabled(&pdev->dev, NULL);
> if (IS_ERR(clk))
> return dev_err_probe(&pdev->dev, PTR_ERR(clk), "failed to find rtc clock\n");
>
> - ret = clk_prepare_enable(clk);
> - if (ret)
> - return ret;
> -
> if (!(rtc_reg_read(rtc, MA35_REG_RTC_INIT) & RTC_INIT_ACTIVE)) {
> ret = ma35d1_rtc_init(rtc, RTC_INIT_TIMEOUT);
> if (ret)
[Severity: High]
This is a pre-existing issue, but does this code fail to handle deferred
probe for the IRQ?
A bit further down in this function, the return value of platform_get_irq()
is assigned directly to rtc->irq_num without checking for negative error
codes:
rtc->irq_num = platform_get_irq(pdev, 0);
ret = devm_request_irq(&pdev->dev, rtc->irq_num, ma35d1_rtc_interrupt,
IRQF_NO_SUSPEND, "ma35d1rtc", rtc);
If platform_get_irq() returns -EPROBE_DEFER, passing that negative value to
devm_request_irq() (which takes an unsigned int) will convert it into a large
positive integer. This causes devm_request_irq() to fail with -EINVAL,
effectively breaking probe deferral and causing a permanent probe failure if
the IRQ controller is not yet ready.
[Severity: High]
This is also a pre-existing issue, but is there a risk of a use-after-free
if the RTC interrupt fires during driver unbind or error handling?
The IRQ is requested early using devm_request_irq():
ret = devm_request_irq(&pdev->dev, rtc->irq_num, ma35d1_rtc_interrupt,
IRQF_NO_SUSPEND, "ma35d1rtc", rtc);
Later in the probe function, the RTC device is allocated and registered:
rtc->rtcdev = devm_rtc_allocate_device(&pdev->dev);
if (IS_ERR(rtc->rtcdev))
return PTR_ERR(rtc->rtcdev);
...
ret = devm_rtc_register_device(rtc->rtcdev);
Because devres cleans up resources in reverse order of allocation (LIFO),
during unbind or if devm_rtc_register_device() fails, the RTC device will
be freed before the IRQ is disabled.
If an RTC alarm goes off in this window, the interrupt handler will execute:
drivers/rtc/rtc-ma35d1.c:ma35d1_rtc_interrupt() {
...
rtc_update_irq(rtc->rtcdev, 1, events);
...
}
Could this pass the already-freed rtc->rtcdev pointer to rtc_update_irq(),
leading to memory corruption?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260914131850.2331670-1-congnt264@gmail.com?part=1
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] rtc: ma35d1: fix permanent clock reference/enable-count leak in probe
2026-09-14 13:18 [PATCH] rtc: ma35d1: fix permanent clock reference/enable-count leak in probe Cong Nguyen
2026-09-14 13:35 ` sashiko-bot
@ 2026-09-15 6:08 ` Jacky Huang
1 sibling, 0 replies; 3+ messages in thread
From: Jacky Huang @ 2026-09-15 6:08 UTC (permalink / raw)
To: Cong Nguyen, Jacky Huang
Cc: Shan-Chun Hung, Alexandre Belloni, linux-arm-kernel, linux-rtc,
linux-kernel
> diff --git a/drivers/rtc/rtc-ma35d1.c b/drivers/rtc/rtc-ma35d1.c
> index cfcfc28060f6..43358d68565a 100644
> --- a/drivers/rtc/rtc-ma35d1.c
> +++ b/drivers/rtc/rtc-ma35d1.c
> @@ -221,14 +221,10 @@ static int ma35d1_rtc_probe(struct platform_device *pdev)
> if (IS_ERR(rtc->rtc_reg))
> return PTR_ERR(rtc->rtc_reg);
>
> - clk = of_clk_get(pdev->dev.of_node, 0);
> + clk = devm_clk_get_enabled(&pdev->dev, NULL);
> if (IS_ERR(clk))
> return dev_err_probe(&pdev->dev, PTR_ERR(clk), "failed to find rtc clock\n");
>
> - ret = clk_prepare_enable(clk);
> - if (ret)
> - return ret;
> -
> if (!(rtc_reg_read(rtc, MA35_REG_RTC_INIT) & RTC_INIT_ACTIVE)) {
> ret = ma35d1_rtc_init(rtc, RTC_INIT_TIMEOUT);
> if (ret)
> --
> 2.25.1
>
Hi Cong,
Thanks for fixing this.
The conversion to devm_clk_get_enabled() correctly fixes the
clock reference and enable-count leak while preserving the RTC
clock behavior during the device lifetime.
Reviewed-by: Jacky Huang <ychuang3@nuvoton.com>
Best regards,
Jacky Huang
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-09-15 6:08 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-14 13:18 [PATCH] rtc: ma35d1: fix permanent clock reference/enable-count leak in probe Cong Nguyen
2026-09-14 13:35 ` sashiko-bot
2026-09-15 6:08 ` Jacky Huang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox