Re: [PATCH 2/3] ASoC: codecs: wcd934x: Make sure clk_init_data is fully initialized

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

Pre-existing issues:
- [High] Use-After-Free of wcd structure due to mismatched devres lifecycles.
--

--- Patch [2]: [PATCH 2/3] ASoC: codecs: wcd934x: Make sure clk_init_data is fully initialized ---
commit ff8f9601f6c3274a4ff6020b3e29ffe892c8e05d
Author: Geert Uytterhoeven <[email protected]>

ASoC: codecs: wcd934x: Make sure clk_init_data is fully initialized

The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues. This commit makes
sure all members are fully initialized.

> diff --git a/sound/soc/codecs/wcd934x.c b/sound/soc/codecs/wcd934x.c
> index caca5cc251004..0ed24cca088f8 100644
> --- a/sound/soc/codecs/wcd934x.c
> +++ b/sound/soc/codecs/wcd934x.c
> @@ -2130,9 +2130,9 @@ static struct clk *wcd934x_register_mclk_output(struct wcd934x_codec *wcd)
>  	struct device *dev = wcd->dev;
>  	struct device_node *np = dev->parent->of_node;
>  	const char *parent_clk_name = NULL;
> +	struct clk_init_data init = {};
>  	const char *clk_name = "mclk";
>  	struct clk_hw *hw;
> -	struct clk_init_data init;
>  	int ret;
>  
>  	if (of_property_read_u32(np, "clock-frequency", &wcd->rate))

[Severity: High]
This is a pre-existing issue, but is there a use-after-free risk due to
mismatched devres lifecycles when the driver is unbound?

The wcd structure is allocated using devm_kzalloc on the codec device's
lifecycle in wcd934x_codec_probe:

sound/soc/codecs/wcd934x.c:wcd934x_codec_probe() {
    ...
    wcd = devm_kzalloc(dev, sizeof(*wcd), GFP_KERNEL);
    ...
}

However, further down in wcd934x_register_mclk_output, the embedded clock
hardware is registered against the parent device's lifecycle:

sound/soc/codecs/wcd934x.c:wcd934x_register_mclk_output() {
    ...
    ret = devm_clk_hw_register(wcd->dev->parent, hw);
    ...
}

When the parent MFD driver is unbound (e.g. via rmmod), the driver core
first unbinds all child devices. The codec device unbinds, freeing wcd.
Then, the parent MFD device unbinds, and its devres cleanup invokes
clk_hw_unregister on the now-freed hw pointer.

Does devm_clk_hw_register need to be called on the child dev instead of
the parent?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2