Re: [PATCH v3 2/4] rtc: pcf85063: do not clear AIE in the interrupt handler

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing cleanup of wake IRQ and wakeup source for the SPI device leads to memory leaks and a use-after-free of the IRQ number upon unbind.
--

commit a20e38cbd0dbed144e6a870cac13aec94ffaa637
Author: Alexander Sverdlin <alexander.sverdlin@siemens.com>

rtc: pcf85063: do not clear AIE in the interrupt handler

The interrupt handler cleared the AIE bit while acknowledging the AF flag, which
could race with process-context updates. The RTC core already manages disabling
the alarm interrupt, so this patch limits the handler to only acknowledging AF.

> diff --git a/drivers/rtc/rtc-pcf85063.c b/drivers/rtc/rtc-pcf85063.c
> index ac9ab1c376c0b..af900fe8ae15e 100644
> --- a/drivers/rtc/rtc-pcf85063.c
> +++ b/drivers/rtc/rtc-pcf85063.c
> @@ -238,8 +238,7 @@ static irqreturn_t pcf85063_rtc_handle_irq(int irq, void *dev_id)
>  	if (val & PCF85063_CTRL2_AF) {
>  		rtc_update_irq(pcf85063->rtc, 1, RTC_IRQF | RTC_AF);
>  		regmap_update_bits(pcf85063->regmap, PCF85063_REG_CTRL2,
> -				   PCF85063_CTRL2_AIE | PCF85063_CTRL2_AF,
> -				   0);
> +				   PCF85063_CTRL2_AF, 0);
>  		return IRQ_HANDLED;
>  	}
>  

[Severity: High]
This is a pre-existing issue, but I noticed a potential leak during driver
unbind for the SPI variant in this file.

In pcf85063_probe(), the wake IRQ and wakeup source are allocated without
using devres:

drivers/rtc/rtc-pcf85063.c:pcf85063_probe() {
    ...
		} else {
			set_bit(RTC_FEATURE_ALARM, pcf85063->rtc->features);
			device_init_wakeup(dev, true);
			err = dev_pm_set_wake_irq(dev, irq);
    ...
}

The SPI subsystem, unlike I2C, does not automatically clear the wake IRQ or
wakeup source on driver removal. Since the rv8063_driver SPI driver lacks a
.remove callback, could this leak the wake IRQ and wakeup source when the
driver is unbound?

drivers/rtc/rtc-pcf85063.c:
static struct spi_driver rv8063_driver = {
	.driver         = {
		.name   = "rv8063",
		.of_match_table = rv8063_of_match,
	},
	.probe          = rv8063_probe,
	.id_table	= rv8063_id,
};

When the driver is unbound, devm_request_threaded_irq() frees the IRQ via
devres, but dev->power.wakeirq still holds the freed IRQ number and the
wakeup_source remains registered. 

If the system subsequently suspends, dev_pm_arm_wake_irq() iterates over
registered wakeup sources and calls enable_irq_wake() with the freed IRQ
number. Could this access a stale IRQ descriptor and interfere with hardware
state, potentially leading to an unhandled IRQ storm on resume?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828164445.3907839-1-alexander.sverdlin@siemens.com?part=2