[alsa-devel] [PATCH] ASoC: soc-core: fix an uninitialized use

[Jian Cai]

Thanks for the pointers. You are absolutely right (despite working late),
this is not an issue upstream anymore. I was looking at 4.14 and 4.19 on
ChromeOS. I did double check the upstream code but stopped right after
seeing 'ret' was still uninitialized. Thanks again for the information.

On Thu, Feb 6, 2020 at 4:04 PM Nick Desaulniers <ndesaulniers at google.com>
wrote:

> On Fri, Feb 7, 2020 at 12:55 AM Jian Cai <caij2003 at gmail.com> wrote:
> >
> > Hi Nick,
> >
> > 'ret' is only defined in if branches and for loops (e.g.
> for_each_component_dais). If none of these branches or loops get executed,
> then eventually we end up having
>
> https://elixir.bootlin.com/linux/latest/source/sound/soc/soc-core.c#L1276
> and
> https://elixir.bootlin.com/linux/latest/source/sound/soc/soc-core.c#L1287
> both assign to `ret` before any `goto` is taken.  Are you perhaps
> looking at an older branch of the LTS tree, but not the master branch
> of the mainline tree? (Or it's possible that it's 1am here in Zurich,
> and I should go to bed).
>
>
> >
> > int ret;
> >
> > err_probe:
> >         if (ret < 0)
> >                 soc_cleanup_component(component);
> >
> > With -ftrivial-auto-var-init=pattern, this code becomes
> >
> > int ret;
> >
> > err_probe:
> >        ret = 0xAAAAAAAA;
> >         if (ret < 0)
> >                 soc_cleanup_component(component);
> >
> > So soc_cleanup_component gets called unintentionally this case, which
> causes the built kernel to miss some files.
> >
> >
> >
> > On Thu, Feb 6, 2020 at 3:28 PM Nick Desaulniers <ndesaulniers at google.com>
> wrote:
> >>
> >> > Fixed the uninitialized use of a signed integer variable ret in
> >> > soc_probe_component when all its definitions are not executed. This
> >> > caused  -ftrivial-auto-var-init=pattern to initialize the variable to
> >> > repeated 0xAA (i.e. a negative value) and triggered the following code
> >> > unintentionally.
> >>
> >> > Signed-off-by: Jian Cai <caij2003 at gmail.com>
> >>
> >> Hi Jian,
> >> I don't quite follow; it looks like `ret` is assigned to multiple times
> in
> >> `soc_probe_component`. Are one of the return values of one of the
> functions
> >> that are called then assigned to `ret` undefined? What control flow
> path leaves
> >> `ret` unitialized?
>
>
>
> --
> Thanks,
> ~Nick Desaulniers
>