Re: [PATCH] rtc: ma35d1: fix permanent clock reference/enable-count leak in probe

[sashiko-bot@kernel.org]

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