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

[Cristian Marussi]

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@xxxxxxx>
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@xxxxxxx>

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