Re: [PATCH 0/3] firmware: arm_scmi: Lazy clock rates and bound iterator fixes

Cristian Marussi
2026-03-23T18:02:30Z

On Mon, Mar 23, 2026 at 05:56:09PM +0100, Geert Uytterhoeven wrote:
> Hi all,

Hi Geert,

>
> This patch series:
> - Fixes an out-of-bound access in lazy clock rate handling,
> - Synchronizes bound-iterator cleanup naming between documentation and
> code.

thanks for this !

I was just chasing down exactly the same issue, since it was flagged by
our CI on a rockchip board (together with some KASAN splat...)...but I had
still to manage to get my hands directly on that board to start
debugging properly ... so ...

... very happy that you beat me at this:P !

While waiting for the board and trying to figure out what could cause
the fatal issue I spotted something more to be rectified in the core of
the iterators, BUT I dont think it would have solved the issue like your
fixes.

In a nutshell, it was the possibility of an integer undeflow due to an
unchecked subtraction between unsigned.

---8<---
commit 65bd4a11333098fbf4c60f3bc59c971be1cd259d (mygitlab/scmi_dev, scmi_dev)
Author: Cristian Marussi <cristian.marussi@arm.com>
Date: Mon Mar 23 08:19:32 2026 +0000

[TODO] FIX Iterator boundary checking

[TODO] FIX Iterator boundary checking

Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>

diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 8b5f477758a0..562977438e60 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -1845,7 +1845,7 @@ static int __scmi_iterator_run(void *iter, unsigned int *start, unsigned int *en
if (ret)
return ret;

- if (st->num_returned > st->max_resources - st->desc_index) {
+ if (st->num_returned + st->desc_index > st->max_resources) {
dev_err(ph->dev,
"No. of resources can't exceed %d\n",
st->max_resources);
---8<----

Anyway, next dsys I will test all of this with your series, but since my
original series indeed was on hold now due to these issues AND because still
lacking clock-MAINTs acks, I am not sure if:

- we'll merge your fixes into my series while maintaining of course your
authorship (instead of applying the series on top)

- Sudeep will still queue any of this for this cycle

Thanks a lot for the debug and fixes to my cr...y stuff :P

Cristian