Re: [PATCH v3 2/7] clk: tests: Add clk_parse_clkspec() Kunit testing

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Pre-existing race condition in `__of_clk_get()` exposing a time-of-check to time-of-use (TOCTOU) use-after-free vulnerability during concurrent clock provider unregistration.
--

--- Patch [2]: [PATCH v3 2/7] clk: tests: Add clk_parse_clkspec() Kunit testing ---
commit b17a28133ab40253da7bfbaf67521eac37a7e21a
Author: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>

clk: tests: Add clk_parse_clkspec() Kunit testing

Create a new set of kunit tests to make sure clk_parse_clkspec() is
working as expected. We currently verify if we get a proper device when
using indexes and names.

> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 048adfa86a5d0..08874cf9b5617 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c

[ ... ]

> @@ -5300,6 +5301,7 @@ struct clk_hw *of_clk_get_hw(struct device_node *np, int index,
>  
>  	return hw;
>  }
> +EXPORT_SYMBOL_IF_KUNIT(of_clk_get_hw);
>  
>  static struct clk *__of_clk_get(struct device_node *np,
>  				int index, const char *dev_id,

[Severity: High]
This is a pre-existing issue, but exposing of_clk_get_hw() brings attention
to how the returned pointer is managed in the surrounding code.

Could a concurrent clock provider unregistration cause a use-after-free
vulnerability here?

Looking at how __of_clk_get() uses the hardware pointer:

__of_clk_get() {
    ...
    hw = of_clk_get_hw(np, index, con_id);
    return clk_hw_create_clk(NULL, hw, dev_id, con_id);
}

When of_clk_get_hw() calls of_clk_get_hw_from_clkspec(), it retrieves the hw
pointer under of_clk_mutex but returns it without incrementing any
underlying reference count.

Once the mutex is released, another thread could unregister the clock
provider, freeing both hw and hw->core.

If that happens before clk_hw_create_clk() executes, does it dereference
the freed pointer when evaluating hw->core and attempting try_module_get()
on core->owner?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716-schneider-v7-2-rc1-eip201-upstream-v3-0-98454e83845c@bootlin.com?part=2