linux-kernel - Re: [PATCH] sound: fix uninit-value in i2s_dma

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e8fe072a-e1b9-41b0-9382-6562139e31d3@gmail.com>
Date: Fri, 1 Nov 2024 14:32:43 +0530
From: Suraj Sonawane <surajsonawane0215@...il.com>
To: Mark Brown <broonie@...nel.org>
Cc: Liam Girdwood <lgirdwood@...il.com>, Jaroslav Kysela <perex@...ex.cz>,
 Takashi Iwai <tiwai@...e.com>, linux-sound@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sound: fix uninit-value in i2s_dma_isr

On 31/10/24 21:47, Mark Brown wrote:
> On Thu, Oct 31, 2024 at 12:17:56PM +0530, Suraj Sonawane wrote:
>> On 30/10/24 22:44, Mark Brown wrote:
> 
>>> This will shut the warning up, but why are these values valid?  Are we
>>> handling the cases where the loops do not execute properly?
> 
>> Thank you for the feedback and your time.
> 
>> The uninitialized warning for val_1 and val_2 arises because, in some cases,
>> the offlevel value is zero, and as a result, the loop does not execute,
>> leaving these variables potentially undefined. The subsequent code
>> calculates prtd->dma_addr_next using val_1 + val_2, so it's necessary to
>> have val_1 and val_2 initialized to a known value, even when the loop does
>> not run.
> 
>> Initializing them to zero ensures prtd->dma_addr_next has a defined value
>> without triggering undefined behavior. However, if a zero initialization
>> could cause unintended behavior in dma_addr_next, I could alternatively
>> handle this case by setting dma_addr_next conditionally when offlevel is
>> non-zero.
> 
> This is describing again what the patch does, which basically just boils
> down to shutting up the warning.
> 
>> Let me know if there’s a preferred approach, or if you'd suggest a different
>> initial value for these variables based on the expected use.
> 
> We need to understand what the change is doing - what do the values
> mean, is the real issue that we're missing some error handling for the
> case that lets us fall through without initialisation?
Thank you for clarifying.

I reviewed the context around val_1 and val_2 in dma_addr_next. These 
values are expected to come from the registers when offlevel is 
non-zero, representing the next DMA address and length information. If 
offlevel is zero, it means there’s no offset data to process, and 
dma_addr_next might not need updating in that case.

A more precise solution would be to conditionally update 
prtd->dma_addr_next only when offlevel is non-zero, as this would 
reflect the intended logic without relying on an arbitrary initialization.

Would it be better to revise the patch to conditionally update 
prtd->dma_addr_next only when offlevel is non-zero?

Let me know if this approach aligns better with the expected behavior.

Thank you again for your time.

Thanks,
Suraj