linux-kernel - Re: [alsa-devel] [PATCH] ASoC: soc-core: Fix null pointer dereference in soc_find

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: <20190115210716.GI5522@sirena.org.uk>
Date:   Tue, 15 Jan 2019 21:07:16 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc:     rohkumar@....qualcomm.com, alsa-devel@...a-project.org,
        bgoswami@...eaurora.org, vinod.koul@...aro.org,
        linux-kernel@...r.kernel.org, plai@...eaurora.org, tiwai@...e.com,
        lgirdwood@...il.com, Ajit Pandey <ajitp@...eaurora.org>,
        Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
        Rohit kumar <rohitkr@...eaurora.org>, asishb@...eaurora.org,
        srinivas.kandagatla@...aro.org
Subject: Re: [alsa-devel] [PATCH] ASoC: soc-core: Fix null pointer
 dereference in soc_find_component

On Tue, Jan 15, 2019 at 01:35:07PM -0600, Pierre-Louis Bossart wrote:
> On 1/14/19 6:06 PM, Mark Brown wrote:

> > just pushing the breakage around rather than fixing it.  Can someone
> > with an x86 system take a look and confirm exactly what's going on with
> > binding these cards please?

> Beyond the fact that the platform_name seems to be totally useless,
> additional tests show that the patch ('ASoC: soc-core: defer card probe
> until all component is added to list') adds a new restriction which
> contradicts existing error checks.

Yes...  I'd been coming to the conclusion that it was a huge red herring
here.  

> So if we want to be consistent, the new code should be something like:

> diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
> index b680c673c553..2791da9417f8 100644
> --- a/sound/soc/soc-core.c
> +++ b/sound/soc/soc-core.c
> @@ -1154,7 +1154,7 @@ static int soc_init_dai_link(struct snd_soc_card
> *card,
>          * Defer card registartion if cpu dai component is not added to
>          * component list.
>          */
> -       if (!soc_find_component(link->cpu_of_node, link->cpu_name))
> +       if (!link->cpu_dai_name && !soc_find_component(link->cpu_of_node,
> link->cpu_name))
>                 return -EPROBE_DEFER;
> 
>         /*

> or try to call soc_find_component with both cpu_name or cpu_dai_name, if
> this makes sense?

I think calling _find_component() makes more sense here as it will do
the check it's actually there thing no matter how the link is
identified.  Assuming that does resolve the issue do you want to make a
patch given that you got there first?

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