Linux RTC
 help / color / mirror / Atom feed
* [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