Fix an issue detected by the Smatch tool:

sound/soc/sof/ipc4-pcm.c: sof_ipc4_pcm_dai_link_fixup_rate()
error: uninitialized symbol 'be_rate'.

This issue occurred because the variable 'be_rate' could remain
uninitialized if num_input_formats is zero. In such cases, the
loop that assigns a value to 'be_rate' would not execute,
potentially leading to undefined behavior when rate->min and
rate->max are set with an uninitialized 'be_rate'.

To resolve this, an additional check for num_input_formats > 0
was added before setting rate->min and rate->max with 'be_rate'.
This ensures that 'be_rate' is assigned only when there are valid
input formats, preventing any use of uninitialized data.

This solution maintains defined behavior for rate->min and rate->max,
ensuring they are only assigned when valid be_rate data is available.

Signed-off-by: Suraj Sonawane <surajsonawane0215@gmail.com>
---
V1: Initialize 'be_rate' to 0.
V2: Add conditional assignment based on num_input_formats to ensure
be_rate is used only when assigned.

 sound/soc/sof/ipc4-pcm.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/sound/soc/sof/ipc4-pcm.c b/sound/soc/sof/ipc4-pcm.c
index 4df2be3d3..d5d7ffc69 100644
--- a/sound/soc/sof/ipc4-pcm.c
+++ b/sound/soc/sof/ipc4-pcm.c
@@ -633,8 +633,11 @@ static int sof_ipc4_pcm_dai_link_fixup_rate(struct snd_sof_dev *sdev,
 			return -EINVAL;
 		}
 
-		rate->min = be_rate;
-		rate->max = rate->min;
+		/* Set rate only if be_rate was assigned */
+		if (num_input_formats > 0) {
+			rate->min = be_rate;
+			rate->max = rate->min;
+		}
 	}
 
 	return 0;
-- 
2.34.1

On 03/11/2024 13:37, Suraj Sonawane wrote:
> Fix an issue detected by the Smatch tool:
> 
> sound/soc/sof/ipc4-pcm.c: sof_ipc4_pcm_dai_link_fixup_rate()
> error: uninitialized symbol 'be_rate'.
> 
> This issue occurred because the variable 'be_rate' could remain
> uninitialized if num_input_formats is zero. In such cases, the
> loop that assigns a value to 'be_rate' would not execute,
> potentially leading to undefined behavior when rate->min and
> rate->max are set with an uninitialized 'be_rate'.
> 
> To resolve this, an additional check for num_input_formats > 0
> was added before setting rate->min and rate->max with 'be_rate'.
> This ensures that 'be_rate' is assigned only when there are valid
> input formats, preventing any use of uninitialized data.
> 
> This solution maintains defined behavior for rate->min and rate->max,
> ensuring they are only assigned when valid be_rate data is available.
> 
> Signed-off-by: Suraj Sonawane <surajsonawane0215@gmail.com>
> ---
> V1: Initialize 'be_rate' to 0.
> V2: Add conditional assignment based on num_input_formats to ensure
> be_rate is used only when assigned.
> 
>  sound/soc/sof/ipc4-pcm.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/sound/soc/sof/ipc4-pcm.c b/sound/soc/sof/ipc4-pcm.c
> index 4df2be3d3..d5d7ffc69 100644
> --- a/sound/soc/sof/ipc4-pcm.c
> +++ b/sound/soc/sof/ipc4-pcm.c
> @@ -633,8 +633,11 @@ static int sof_ipc4_pcm_dai_link_fixup_rate(struct snd_sof_dev *sdev,
>  			return -EINVAL;
>  		}
>  
> -		rate->min = be_rate;
> -		rate->max = rate->min;
> +		/* Set rate only if be_rate was assigned */
> +		if (num_input_formats > 0) {

By definition the copier must have at least one input and one output
format, this check is going to be always true.

> +			rate->min = be_rate;
> +			rate->max = rate->min;
> +		}
>  	}
>  
>  	return 0;

-- 
Péter

On 04/11/24 16:22, Péter Ujfalusi wrote:
> 
> 
> On 03/11/2024 13:37, Suraj Sonawane wrote:
>> Fix an issue detected by the Smatch tool:
>>
>> sound/soc/sof/ipc4-pcm.c: sof_ipc4_pcm_dai_link_fixup_rate()
>> error: uninitialized symbol 'be_rate'.
>>
>> This issue occurred because the variable 'be_rate' could remain
>> uninitialized if num_input_formats is zero. In such cases, the
>> loop that assigns a value to 'be_rate' would not execute,
>> potentially leading to undefined behavior when rate->min and
>> rate->max are set with an uninitialized 'be_rate'.
>>
>> To resolve this, an additional check for num_input_formats > 0
>> was added before setting rate->min and rate->max with 'be_rate'.
>> This ensures that 'be_rate' is assigned only when there are valid
>> input formats, preventing any use of uninitialized data.
>>
>> This solution maintains defined behavior for rate->min and rate->max,
>> ensuring they are only assigned when valid be_rate data is available.
>>
>> Signed-off-by: Suraj Sonawane <surajsonawane0215@gmail.com>
>> ---
>> V1: Initialize 'be_rate' to 0.
>> V2: Add conditional assignment based on num_input_formats to ensure
>> be_rate is used only when assigned.
>>
>>   sound/soc/sof/ipc4-pcm.c | 7 +++++--
>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/sound/soc/sof/ipc4-pcm.c b/sound/soc/sof/ipc4-pcm.c
>> index 4df2be3d3..d5d7ffc69 100644
>> --- a/sound/soc/sof/ipc4-pcm.c
>> +++ b/sound/soc/sof/ipc4-pcm.c
>> @@ -633,8 +633,11 @@ static int sof_ipc4_pcm_dai_link_fixup_rate(struct snd_sof_dev *sdev,
>>   			return -EINVAL;
>>   		}
>>   
>> -		rate->min = be_rate;
>> -		rate->max = rate->min;
>> +		/* Set rate only if be_rate was assigned */
>> +		if (num_input_formats > 0) {
> 
> By definition the copier must have at least one input and one output
> format, this check is going to be always true.
> 
>> +			rate->min = be_rate;
>> +			rate->max = rate->min;
>> +		}
>>   	}
>>   
>>   	return 0;
> 
Thank you for the clarification.

On Mon, Nov 04, 2024 at 12:52:09PM +0200, Péter Ujfalusi wrote:
> On 03/11/2024 13:37, Suraj Sonawane wrote:

> > Fix an issue detected by the Smatch tool:
> > 
> > sound/soc/sof/ipc4-pcm.c: sof_ipc4_pcm_dai_link_fixup_rate()
> > error: uninitialized symbol 'be_rate'.
> > 
> > This issue occurred because the variable 'be_rate' could remain
> > uninitialized if num_input_formats is zero. In such cases, the
> > loop that assigns a value to 'be_rate' would not execute,
> > potentially leading to undefined behavior when rate->min and
> > rate->max are set with an uninitialized 'be_rate'.
> > 
> > To resolve this, an additional check for num_input_formats > 0
> > was added before setting rate->min and rate->max with 'be_rate'.
> > This ensures that 'be_rate' is assigned only when there are valid
> > input formats, preventing any use of uninitialized data.

> > -		rate->min = be_rate;
> > -		rate->max = rate->min;
> > +		/* Set rate only if be_rate was assigned */
> > +		if (num_input_formats > 0) {

> By definition the copier must have at least one input and one output
> format, this check is going to be always true.

Static analysis of the code can't reasonably tell that, we need
something that ensures that it doesn't detect a spuriously uninitialised
variable here.  Possibly a

	if (WARN_ON_ONCE(!num_input_formats))
		return -EINVAL;

or similar?

On 04/11/24 23:57, Mark Brown wrote:
> On Mon, Nov 04, 2024 at 12:52:09PM +0200, Péter Ujfalusi wrote:
>> On 03/11/2024 13:37, Suraj Sonawane wrote:
> 
>>> Fix an issue detected by the Smatch tool:
>>>
>>> sound/soc/sof/ipc4-pcm.c: sof_ipc4_pcm_dai_link_fixup_rate()
>>> error: uninitialized symbol 'be_rate'.
>>>
>>> This issue occurred because the variable 'be_rate' could remain
>>> uninitialized if num_input_formats is zero. In such cases, the
>>> loop that assigns a value to 'be_rate' would not execute,
>>> potentially leading to undefined behavior when rate->min and
>>> rate->max are set with an uninitialized 'be_rate'.
>>>
>>> To resolve this, an additional check for num_input_formats > 0
>>> was added before setting rate->min and rate->max with 'be_rate'.
>>> This ensures that 'be_rate' is assigned only when there are valid
>>> input formats, preventing any use of uninitialized data.
> 
>>> -		rate->min = be_rate;
>>> -		rate->max = rate->min;
>>> +		/* Set rate only if be_rate was assigned */
>>> +		if (num_input_formats > 0) {
> 
>> By definition the copier must have at least one input and one output
>> format, this check is going to be always true.
> 
> Static analysis of the code can't reasonably tell that, we need
> something that ensures that it doesn't detect a spuriously uninitialised
> variable here.  Possibly a
> 
> 	if (WARN_ON_ONCE(!num_input_formats))
> 		return -EINVAL;
> 
> or similar?

Thank you, Mark and Péter, for the guidance. I understand now that, 
while the copier should always have at least one input format, static 
analysis tools can’t detect this. Based on your suggestions, I’ve 
considered the following possible solutions to address the issue:

1. Add a WARN_ON_ONCE(!num_input_formats) check: This would issue a 
warning and return an error if num_input_formats is unexpectedly zero, 
ensuring we handle any edge cases explicitly.

2. Return an error if no input formats are available: Implementing the 
following check could provide immediate feedback if num_input_formats is 
zero:
     if (num_input_formats <= 0) {
         dev_err(sdev->dev, "No input formats available\n");
         return -EINVAL; // Return an error if there are no formats
     }

Would it be preferable to proceed with the 
WARN_ON_ONCE(!num_input_formats) approach, or is there a preferred 
alternative from the options above?

Thank you again

On Tue, Nov 05, 2024 at 04:20:23PM +0530, Suraj Sonawane wrote:

> Thank you, Mark and Péter, for the guidance. I understand now that, while
> the copier should always have at least one input format, static analysis
> tools can’t detect this. Based on your suggestions, I’ve considered the
> following possible solutions to address the issue:

> 1. Add a WARN_ON_ONCE(!num_input_formats) check: This would issue a warning
> and return an error if num_input_formats is unexpectedly zero, ensuring we
> handle any edge cases explicitly.

> 2. Return an error if no input formats are available: Implementing the
> following check could provide immediate feedback if num_input_formats is
> zero:
>     if (num_input_formats <= 0) {
>         dev_err(sdev->dev, "No input formats available\n");
>         return -EINVAL; // Return an error if there are no formats
>     }

> Would it be preferable to proceed with the WARN_ON_ONCE(!num_input_formats)
> approach, or is there a preferred alternative from the options above?

I don't have a super strong preference between the two options.

On 06/11/24 00:37, Mark Brown wrote:
> On Tue, Nov 05, 2024 at 04:20:23PM +0530, Suraj Sonawane wrote:
> 
>> Thank you, Mark and Péter, for the guidance. I understand now that, while
>> the copier should always have at least one input format, static analysis
>> tools can’t detect this. Based on your suggestions, I’ve considered the
>> following possible solutions to address the issue:
> 
>> 1. Add a WARN_ON_ONCE(!num_input_formats) check: This would issue a warning
>> and return an error if num_input_formats is unexpectedly zero, ensuring we
>> handle any edge cases explicitly.
> 
>> 2. Return an error if no input formats are available: Implementing the
>> following check could provide immediate feedback if num_input_formats is
>> zero:
>>      if (num_input_formats <= 0) {
>>          dev_err(sdev->dev, "No input formats available\n");
>>          return -EINVAL; // Return an error if there are no formats
>>      }
> 
>> Would it be preferable to proceed with the WARN_ON_ONCE(!num_input_formats)
>> approach, or is there a preferred alternative from the options above?
> 
> I don't have a super strong preference between the two options.
Thank you for the clarification. I’ll study the best approach in more 
detail and will send the patch in a while.

Thanks again for your time and feedback!