[PATCH 0/3] ASoC: Make sure clk_init_data is fully initialized

[PATCH 0/3] ASoC: Make sure clk_init_data is fully initialized

[Geert Uytterhoeven]

	Hi all,

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, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.

Hence this series aims to make sure all members are fully initialized,
to avoid such bugs, and to prevent future breakage when converting
drivers to a different method for specifying the parents.

Part One[1] fixed all cases that I identified to be real bugs, in
response to a crash I saw on BeagleBone Black.

This series is the ASoC subpart of Part Two, which fixes remaining cases
that are currently harmless.  These are still fragile, and may cause
future breakage when converting drivers to a different method for
specifying the parents.

Thanks for your comments!

[1] "[PATCH treewide 0/5] clk: Make sure clk_init_data is fully
     initialized (part 1)"
    https://lore.kernel.org/cover.1787165329.git.geert+renesas@glider.be

Geert Uytterhoeven (3):
  ASoC: codecs: lpass: Make sure clk_init_data is fully initialized
  ASoC: codecs: wcd934x: Make sure clk_init_data is fully initialized
  ASoC: tlv320aic32x4: Make sure clk_init_data is fully initialized

 sound/soc/codecs/lpass-rx-macro.c    | 2 +-
 sound/soc/codecs/lpass-tx-macro.c    | 2 +-
 sound/soc/codecs/lpass-va-macro.c    | 2 +-
 sound/soc/codecs/lpass-wsa-macro.c   | 2 +-
 sound/soc/codecs/tlv320aic32x4-clk.c | 2 +-
 sound/soc/codecs/wcd934x.c           | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.43.0

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[PATCH 1/3] ASoC: codecs: lpass: Make sure clk_init_data is fully initialized

[Geert Uytterhoeven]

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, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.

Make sure all members are fully initialized, to avoid such bugs, and to
prevent future breakage when converting drivers to a different method
for specifying the parents.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Compile-tested only.
---
 sound/soc/codecs/lpass-rx-macro.c  | 2 +-
 sound/soc/codecs/lpass-tx-macro.c  | 2 +-
 sound/soc/codecs/lpass-va-macro.c  | 2 +-
 sound/soc/codecs/lpass-wsa-macro.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/soc/codecs/lpass-rx-macro.c b/sound/soc/codecs/lpass-rx-macro.c
index 282a6aaa9986554d..2e74ec1a52f8a0f7 100644
--- a/sound/soc/codecs/lpass-rx-macro.c
+++ b/sound/soc/codecs/lpass-rx-macro.c
@@ -3732,8 +3732,8 @@ static int rx_macro_register_mclk_output(struct rx_macro *rx)
 	struct device *dev = rx->dev;
 	const char *parent_clk_name = NULL;
 	const char *clk_name = "lpass-rx-mclk";
+	struct clk_init_data init = {};
 	struct clk_hw *hw;
-	struct clk_init_data init;
 	int ret;
 
 	if (rx->npl)
diff --git a/sound/soc/codecs/lpass-tx-macro.c b/sound/soc/codecs/lpass-tx-macro.c
index a8e83eb60ba2d762..4ac8a11f30621c0b 100644
--- a/sound/soc/codecs/lpass-tx-macro.c
+++ b/sound/soc/codecs/lpass-tx-macro.c
@@ -2210,8 +2210,8 @@ static int tx_macro_register_mclk_output(struct tx_macro *tx)
 	struct device *dev = tx->dev;
 	const char *parent_clk_name = NULL;
 	const char *clk_name = "lpass-tx-mclk";
+	struct clk_init_data init = {};
 	struct clk_hw *hw;
-	struct clk_init_data init;
 	int ret;
 
 	if (tx->npl)
diff --git a/sound/soc/codecs/lpass-va-macro.c b/sound/soc/codecs/lpass-va-macro.c
index dbc5795b9273f131..a3b3af0d7db3cf1f 100644
--- a/sound/soc/codecs/lpass-va-macro.c
+++ b/sound/soc/codecs/lpass-va-macro.c
@@ -1414,7 +1414,7 @@ static int va_macro_register_fsgen_output(struct va_macro *va)
 	struct device_node *np = dev->of_node;
 	const char *parent_clk_name;
 	const char *clk_name = "fsgen";
-	struct clk_init_data init;
+	struct clk_init_data init = {};
 	int ret;
 
 	if (va->has_npl_clk)
diff --git a/sound/soc/codecs/lpass-wsa-macro.c b/sound/soc/codecs/lpass-wsa-macro.c
index cfd2ac0a6cdac4af..f6ef7f188b1ad408 100644
--- a/sound/soc/codecs/lpass-wsa-macro.c
+++ b/sound/soc/codecs/lpass-wsa-macro.c
@@ -2638,10 +2638,10 @@ static const struct clk_ops swclk_gate_ops = {
 
 static int wsa_macro_register_mclk_output(struct wsa_macro *wsa)
 {
+	struct clk_init_data init = {};
 	struct device *dev = wsa->dev;
 	const char *parent_clk_name;
 	struct clk_hw *hw;
-	struct clk_init_data init;
 	int ret;
 
 	if (wsa->npl)
-- 
2.43.0

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

[Geert Uytterhoeven]

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, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.

Make sure all members are fully initialized, to avoid such bugs, and to
prevent future breakage when converting drivers to a different method
for specifying the parents.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Compile-tested only.
---
 sound/soc/codecs/wcd934x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/wcd934x.c b/sound/soc/codecs/wcd934x.c
index caca5cc2510040d6..0ed24cca088f8392 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))
-- 
2.43.0

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

[sashiko-bot]

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 <geert+renesas@glider.be>

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/cover.1787239902.git.geert+renesas@glider.be?part=2

[PATCH 3/3] ASoC: tlv320aic32x4: Make sure clk_init_data is fully initialized

[Geert Uytterhoeven]

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, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.

Make sure all members are fully initialized, to avoid such bugs, and to
prevent future breakage when converting drivers to a different method
for specifying the parents.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Compile-tested only.
---
 sound/soc/codecs/tlv320aic32x4-clk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/tlv320aic32x4-clk.c b/sound/soc/codecs/tlv320aic32x4-clk.c
index deed61650e09db0b..ad15ce9c607915e4 100644
--- a/sound/soc/codecs/tlv320aic32x4-clk.c
+++ b/sound/soc/codecs/tlv320aic32x4-clk.c
@@ -451,8 +451,8 @@ static struct aic32x4_clkdesc aic32x4_clkdesc_array[] = {
 static struct clk *aic32x4_register_clk(struct device *dev,
 					struct aic32x4_clkdesc *desc)
 {
-	struct clk_init_data init;
 	struct clk_aic32x4 *priv;
+	struct clk_init_data init = {};
 	const char *devname = dev_name(dev);
 
 	init.ops = desc->ops;
-- 
2.43.0

Re: [PATCH 3/3] ASoC: tlv320aic32x4: Make sure clk_init_data is fully initialized

[sashiko-bot]

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

Pre-existing issues:
- [High] Memory leak and Use-After-Free via unmanaged clk_lookup entries.
- [High] Data race and stack Use-After-Free due to assigning a block-scoped compound literal to a global array.
- [High] Unchecked return values of resource allocations and clock registrations mask initialization failures.
- [High] Hardcoded clock names cause registration failures for multiple codec instances.
- [High] Unvalidated requested clock rate causes a division by zero panic.
- [High] Unvalidated parent clock rate causes a division by zero panic.
--

--- Patch [3]: [PATCH 3/3] ASoC: tlv320aic32x4: Make sure clk_init_data is fully initialized ---
commit bdb202ba7d1e5e85e1733f12689e1c8729d8c7d3
Author: Geert Uytterhoeven <geert+renesas@glider.be>

ASoC: tlv320aic32x4: 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, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.

Make sure all members are fully initialized, to avoid such bugs, and to
prevent future breakage when converting drivers to a different method
for specifying the parents.

> diff --git a/sound/soc/codecs/tlv320aic32x4-clk.c b/sound/soc/codecs/tlv320aic32x4-clk.c
> index deed61650e09d..ad15ce9c60791 100644
> --- a/sound/soc/codecs/tlv320aic32x4-clk.c
> +++ b/sound/soc/codecs/tlv320aic32x4-clk.c
> @@ -451,8 +451,8 @@ static struct aic32x4_clkdesc aic32x4_clkdesc_array[] = {
>  static struct clk *aic32x4_register_clk(struct device *dev,
>  					struct aic32x4_clkdesc *desc)
>  {
> -	struct clk_init_data init;
>  	struct clk_aic32x4 *priv;
> +	struct clk_init_data init = {};
>  	const char *devname = dev_name(dev);
>  
>  	init.ops = desc->ops;

[Severity: High]
This isn't a bug introduced by this patch, but does hardcoding the clock
name directly from the static descriptor (init.name = desc->name) prevent
probing multiple instances of this codec?

If devm_clk_register() is called on a system with multiple codecs, will
it fail with -EEXIST because names like 'pll' and 'codec_clkin' are reused?


While reviewing this file, I noticed a few other pre-existing regressions:

[Severity: High]
This is a pre-existing issue, but is there a clk_lookup entry leaked when
the device is unbound?

sound/soc/codecs/tlv320aic32x4-clk.c:aic32x4_register_clk() {
    ...
	clk_hw_register_clkdev(&priv->hw, desc->name, devname);
	return devm_clk_register(dev, &priv->hw);
}

Since clk_hw_register_clkdev() dynamically allocates a clk_lookup on the
global list without using a devres variant or dropping it in teardown,
will the lookup retain a dangling pointer to the freed priv->hw if probe
fails or the driver is unbound?


[Severity: High]
This isn't a bug introduced by this patch, but is stack memory being written
into the static global aic32x4_clkdesc_array?

sound/soc/codecs/tlv320aic32x4-clk.c:aic32x4_register_clocks() {
    ...
	aic32x4_clkdesc_array[0].parent_names =
			(const char* []) { mclk_name, "bclk", "gpio", "din" };
	aic32x4_clkdesc_array[1].parent_names =
			(const char *[]) { mclk_name, "bclk", "gpio", "pll" };
    ...
}

Because these compound literals are block-scoped (stack allocated), if this
function returns, won't the global array point to dead stack memory, leading
to a use-after-free when the clock framework reads the parent names?


[Severity: High]
This is a pre-existing issue, but are we discarding the return value of
aic32x4_register_clk() and masking probe failures?

sound/soc/codecs/tlv320aic32x4-clk.c:aic32x4_register_clocks() {
    ...
	for (i = 0; i < ARRAY_SIZE(aic32x4_clkdesc_array); ++i)
		aic32x4_register_clk(dev, &aic32x4_clkdesc_array[i]);

	return 0;
}

If aic32x4_register_clk() fails due to low memory or clock name collisions,
will the driver falsely report a successful probe?


[Severity: High]
This isn't a bug introduced by this patch, but could DIV_ROUND_UP() trigger a
division by zero panic?

sound/soc/codecs/tlv320aic32x4-clk.c:clk_aic32x4_div_determine_rate() {
    ...
	divisor = DIV_ROUND_UP(req->best_parent_rate, req->rate);
    ...
}

If a 0 rate is supplied via the Common Clock Framework API, will this
cause a kernel panic?

This same pattern also appears in clk_aic32x4_div_set_rate() where
DIV_ROUND_UP(parent_rate, rate) is called.


[Severity: High]
This is a pre-existing issue, but might do_div() trigger a division by
zero panic?

sound/soc/codecs/tlv320aic32x4-clk.c:clk_aic32x4_pll_calc_muldiv() {
    ...
	multiplier = (u64)rate * settings->p * 10000;
	do_div(multiplier, parent_rate);
    ...
}

If the PLL clock is queried or set when its parent clock is uninitialized or
reporting a 0 Hz rate, will do_div() divide by zero?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1787239902.git.geert+renesas@glider.be?part=3