Re: [PATCH v2 3/5] rtc: s35390a: Fix alarm not disabling
[email protected] Sat, 01 Aug 2026 18:55:28 +0000
| Newsgroups | org.kernel.vger.linux-rtc,org.kernel.vger.linux-devicetree |
|---|---|
| Message-ID | <[email protected]> |
Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [High] Uninitialized stack memory usage in `s35390a_rtc_alarm_irq_enable`= corrupts the RTC hardware state and cached alarm time. -- --- Patch [3]: [PATCH v2 3/5] rtc: s35390a: Fix alarm not disabling --- commit 14759f80e44e19699052dca75586c20731eb4d5d Author: Markus Probst <[email protected]> rtc: s35390a: Fix alarm not disabling This commit implements the alarm_irq_enable callback to disable the alarm if requested. It also restores the last used alarm time when the alarm is re-enabled. > diff --git a/drivers/rtc/rtc-s35390a.c b/drivers/rtc/rtc-s35390a.c > index 4cfe7034c5165..fbf5471eb3d0b 100644 > --- a/drivers/rtc/rtc-s35390a.c > +++ b/drivers/rtc/rtc-s35390a.c [ ... ] > @@ -379,6 +383,19 @@ static int s35390a_rtc_read_alarm(struct device *dev= , struct rtc_wkalrm *alm) > return 0; > } > =20 > +static int s35390a_rtc_alarm_irq_enable(struct device *dev, unsigned int= enabled) > +{ > + struct s35390a *s35390a =3D dev_get_drvdata(dev); > + struct rtc_wkalrm alm; > + > + alm.enabled =3D enabled; > + > + if (enabled) > + alm.time =3D s35390a->tm_alarm; > + > + return s35390a_rtc_set_alarm(dev, &alm); > +} [Severity: High] When s35390a_rtc_alarm_irq_enable() is called with enabled =3D=3D 0, the al= m.time field remains uninitialized on the stack. Since alm is passed to s35390a_rtc_set_alarm(), won't the uninitialized alm.time be read by the dev_dbg() call at the start of that function? Additionally, does this uninitialized memory overwrite the cached alarm tim= e? Looking at the earlier changes to s35390a_rtc_set_alarm(): s35390a_rtc_set_alarm() ... if (!err) s35390a->tm_alarm =3D alm->time; It appears the uninitialized stack memory can be assigned to s35390a->tm_al= arm, which would permanently corrupt the cache. When the alarm is subsequently re-enabled, this corrupted time would then be restored and written to the hardware. Could this be resolved by zero-initializing the alm structure? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260801-rtc_s35390= [email protected]?part=3D3