Re: [PATCH RFC v5 10/12] clk: zte: Introduce a driver for zx297520v3 LSP clocks and resets

[sashiko-bot@kernel.org]

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

New issues:
- [High] Missing NULL check on device_get_match_data() return value.

Pre-existing issues:
- [High] Double-free of 'adev' during the error path of 'auxiliary_device_add()' in 'zx_clk_common_probe()'.
--

commit 8049f2134eca9c93f09de3be7599856e5b1b9d3c
Author: Stefan Dösinger <stefandoesinger@gmail.com>

clk: zte: Introduce a driver for zx297520v3 LSP clocks and resets

This commit introduces a new driver for the ZTE zx297520v3 LSP clocks and
resets. It defines multiplexers, dividers, and gates for the subsystem. It
also registers the clock provider and optionally an auxiliary device for
the resets.

> diff --git a/drivers/clk/zte/clk-zx297520v3.c b/drivers/clk/zte/clk-zx297520v3.c
> index 17e1f741b48c9..f4ab065ee4969 100644
> --- a/drivers/clk/zte/clk-zx297520v3.c
> +++ b/drivers/clk/zte/clk-zx297520v3.c

[ ... ]

> +static const struct zx_clk_data zx297520v3_lsprm_data = {
> +	.inputs_enable = zx297520v3_lsp_inputs_enable,
> +	.num_inputs_enable = ARRAY_SIZE(zx297520v3_lsp_inputs_enable),
> +	.inputs = zx297520v3_lsp_inputs,
> +	.num_inputs = ARRAY_SIZE(zx297520v3_lsp_inputs),
> +	.muxes = zx297520v3_lsp_muxes,
> +	.num_muxes = ARRAY_SIZE(zx297520v3_lsp_muxes),
> +	.divs = zx297520v3_lsp_dividers,
> +	.num_divs = ARRAY_SIZE(zx297520v3_lsp_dividers),
> +	.gates = zx297520v3_lsp_gates,
> +	.num_gates = ARRAY_SIZE(zx297520v3_lsp_gates),
> +	.reset_auxdev_name = "zx297520v3_lsprst"
> +};

[Severity: High]
This isn't a bug introduced by this patch, but populating reset_auxdev_name
here exposes a double-free bug in the error handling path of
zx_clk_common_probe() in drivers/clk/zte/clk-zx.c.

If auxiliary_device_add() fails during probe, the code jumps to adev_uninit:

drivers/clk/zte/clk-zx.c:zx_clk_common_probe() {
    ...
adev_uninit:
	auxiliary_device_uninit(adev);
adev_free:
	kfree(adev);
	return res;
}

The call to auxiliary_device_uninit() triggers the release callback,
zx_adev_release(), which frees adev. Execution then falls through to adev_free
and calls kfree(adev) a second time.

Could this lead to memory corruption or a kernel panic if probe fails?

[ ... ]

> +static int zx297520v3_lspclk_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +
> +	return zx_clk_common_probe(dev, dev->of_node, device_get_match_data(dev));
> +}

[Severity: High]
Could device_get_match_data() return NULL here and cause a NULL pointer
dereference?

If a user binds the driver via sysfs (using driver_override and bind) to a
device that does not match the driver's of_match_table, device_get_match_data()
will return NULL.

Since zx_clk_common_probe() assumes the data pointer is valid and dereferences
it unconditionally once device_node_to_regmap() succeeds (e.g., data->num_plls),
would this lead to a kernel panic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260628-zx29clk-v5-0-79ff044e4192@gmail.com?part=10