Re: [PATCH v4 7/7] clk: tests: Add Kunit testing for nexus nodes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] `of_find_node_by_name_kunit()` creates a double-free / use-after-free trap via its `from` argument.
- [Medium] `of_find_node_by_name_kunit()` returns an `ERR_PTR` on failure, breaking the expected `NULL` failure semantic of `of_find_node_by_name()`.
--

--- Patch [7]: [PATCH v4 7/7] clk: tests: Add Kunit testing for nexus nodes ---
commit abd4c1ecb509bcaa0e834d4c06b41750affacb27
Author: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>

clk: tests: Add Kunit testing for nexus nodes

Add a nexus node with a child requesting a mapped clock in the fake DT
overlay to verify that the parsing is also correctly working. Create an
of_find_node_by_name() like kunit helper to garbage collect the node
automatically in case of failed assertion.

> diff --git a/drivers/clk/clk_kunit_helpers.c b/drivers/clk/clk_kunit_helpers.c
> index 68a28e70bb61c..daaf1cf1546c4 100644
> --- a/drivers/clk/clk_kunit_helpers.c
> +++ b/drivers/clk/clk_kunit_helpers.c
[ ... ]
> +struct device_node *of_find_node_by_name_kunit(struct kunit *test, struct device_node *from,
> +					       const char *name)
> +{
> +	struct device_node *np;
> +	int ret;
> +
> +	np = of_find_node_by_name(from, name);

[Severity: Medium]
Will this lead to a double-free if the from argument is another
KUnit-managed node?

of_find_node_by_name() explicitly drops the reference on its from argument.
If a test author passes a node previously returned by
of_find_node_by_name_kunit(), the underlying of_find_node_by_name() will
consume the reference immediately.

KUnit is unaware of this and will execute its deferred action at the end of the
test, calling of_node_put() a second time on the already freed node.

> +	if (!np)
> +		return NULL;
> +
> +	ret = kunit_add_action_or_reset(test, of_node_put_wrapper, np);
> +	if (ret)
> +		return ERR_PTR(ret);

[Severity: Medium]
Could this ERR_PTR() return value cause crashes for callers using standard OF
node pointer checks?

The standard of_find_node_by_name() strictly returns NULL on failure, and
callers typically check for failure using if (!np). Returning an ERR_PTR()
here means truthy checks will pass, potentially leading to an invalid pointer
dereference when the caller attempts to use the returned error pointer as a
device_node struct.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-schneider-v7-2-rc1-eip201-upstream-v4-0-751547e160e5@bootlin.com?part=7