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: <d97a58c7-347b-48f9-aa69-d4ff5a4038e3@sirena.org.uk>
Date: Thu, 31 Oct 2024 16:17:08 +0000
From: Mark Brown <broonie@...nel.org>
To: Suraj Sonawane <surajsonawane0215@...il.com>
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 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?

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)