From: Arnd Bergmann <[email protected]>
gcc points out a memory area that is copied to a device
but not initialized:
sound/soc/codecs/cros_ec_codec.c: In function 'i2s_rx_event':
arch/x86/include/asm/string_32.h:83:20: error: '*((void *)&p+4)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
83 | *((int *)to + 1) = *((int *)from + 1);
Initialize all the unused fields to zero.
Fixes: 727f1c71c780 ("ASoC: cros_ec_codec: refactor I2S RX")
Signed-off-by: Arnd Bergmann <[email protected]>
---
sound/soc/codecs/cros_ec_codec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/cros_ec_codec.c b/sound/soc/codecs/cros_ec_codec.c
index 58894bf47514..f33a2a9654e7 100644
--- a/sound/soc/codecs/cros_ec_codec.c
+++ b/sound/soc/codecs/cros_ec_codec.c
@@ -332,7 +332,7 @@ static int i2s_rx_event(struct snd_soc_dapm_widget *w,
snd_soc_dapm_to_component(w->dapm);
struct cros_ec_codec_priv *priv =
snd_soc_component_get_drvdata(component);
- struct ec_param_ec_codec_i2s_rx p;
+ struct ec_param_ec_codec_i2s_rx p = {};
switch (event) {
case SND_SOC_DAPM_PRE_PMU:
--
2.27.0
On Fri, Dec 4, 2020 at 6:55 AM Arnd Bergmann <[email protected]> wrote:
>
> From: Arnd Bergmann <[email protected]>
>
> gcc points out a memory area that is copied to a device
> but not initialized:
>
> sound/soc/codecs/cros_ec_codec.c: In function 'i2s_rx_event':
> arch/x86/include/asm/string_32.h:83:20: error: '*((void *)&p+4)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 83 | *((int *)to + 1) = *((int *)from + 1);
>
> Initialize all the unused fields to zero.
>
> Fixes: 727f1c71c780 ("ASoC: cros_ec_codec: refactor I2S RX")
> Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Tzung-Bi Shih <[email protected]>
In the case in i2s_rx_event(), only the "cmd" member is used. But it
is fine to please the compiler.
struct __ec_align4 ec_param_ec_codec_i2s_rx {
uint8_t cmd; /* enum ec_codec_i2s_rx_subcmd */
uint8_t reserved[3];
union {
...
};
};
I am a bit curious about, in other use cases of
ec_param_ec_codec_i2s_rx, why the compiler doesn't complain about
uninitialization of the "reserved" member?
On Fri, Dec 4, 2020 at 3:56 AM Tzung-Bi Shih <[email protected]> wrote:
>
> On Fri, Dec 4, 2020 at 6:55 AM Arnd Bergmann <[email protected]> wrote:
> >
> > From: Arnd Bergmann <[email protected]>
> >
> > gcc points out a memory area that is copied to a device
> > but not initialized:
> >
> > sound/soc/codecs/cros_ec_codec.c: In function 'i2s_rx_event':
> > arch/x86/include/asm/string_32.h:83:20: error: '*((void *)&p+4)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > 83 | *((int *)to + 1) = *((int *)from + 1);
> >
> > Initialize all the unused fields to zero.
> >
> > Fixes: 727f1c71c780 ("ASoC: cros_ec_codec: refactor I2S RX")
> > Signed-off-by: Arnd Bergmann <[email protected]>
>
> Acked-by: Tzung-Bi Shih <[email protected]>
>
> In the case in i2s_rx_event(), only the "cmd" member is used. But it
> is fine to please the compiler.
I wouldn't do it just to please the compiler. I sent this patch since
the code clearly copies the uninitialized data here. If only
one byte is meant to be copied, then we should change the
function call to not pass the entire structure. I'll send a new
patch for that.
> struct __ec_align4 ec_param_ec_codec_i2s_rx {
> uint8_t cmd; /* enum ec_codec_i2s_rx_subcmd */
> uint8_t reserved[3];
>
> union {
> ...
> };
> };
>
> I am a bit curious about, in other use cases of
> ec_param_ec_codec_i2s_rx, why the compiler doesn't complain about
> uninitialization of the "reserved" member?
The -Wmaybe-uninitialized warning is fundamentally unreliable.
In this case, the __constant_memcpy() function accesses the
members one at a time, and the warning is for the first 'int' array
member that is completely uninitialized, while the 'reserved'
part of the structure is still in the first 'int' that is partially initialized.
Arnd
On Fri, Dec 4, 2020 at 4:28 PM Arnd Bergmann <[email protected]> wrote:
>
> On Fri, Dec 4, 2020 at 3:56 AM Tzung-Bi Shih <[email protected]> wrote:
> >
> > On Fri, Dec 4, 2020 at 6:55 AM Arnd Bergmann <[email protected]> wrote:
> >
> > In the case in i2s_rx_event(), only the "cmd" member is used. But it
> > is fine to please the compiler.
>
> I wouldn't do it just to please the compiler. I sent this patch since
> the code clearly copies the uninitialized data here. If only
> one byte is meant to be copied, then we should change the
> function call to not pass the entire structure. I'll send a new
> patch for that.
My sentence may confuse you. But I mean: the uninitialized data
doesn't introduce any bugs because it only uses the first byte in the
case.
Instead of your v2
(https://patchwork.kernel.org/project/alsa-devel/patch/[email protected]/),
I prefer this version v1.
On Thu, 3 Dec 2020 23:54:41 +0100, Arnd Bergmann wrote:
> gcc points out a memory area that is copied to a device
> but not initialized:
>
> sound/soc/codecs/cros_ec_codec.c: In function 'i2s_rx_event':
> arch/x86/include/asm/string_32.h:83:20: error: '*((void *)&p+4)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 83 | *((int *)to + 1) = *((int *)from + 1);
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: cros_ec_codec: fix uninitialized memory read
commit: 7061b8a52296e044eed47b605d136a48da1a7761
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark