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]

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

On Tue, Jan 15, 2019 at 09:41:38PM +0000, Mark Brown wrote:
> On Tue, Jan 15, 2019 at 03:16:57PM -0600, Pierre-Louis Bossart wrote:
> 
> > > Maybe the defer card probe logic needs to be extended to also check if
> > > dai_link_name had already been registered (either cpu or cpu_dai_name
> > > needs to be set), not 100% sure which problem the defer card probe patch
> > > was trying to solve.
> 
> We were getting cards probing without the platforms being registered
> (which in turn meant we were just skipping their init) and had patches
> proposed to implement the deferral in the cards.  The deferral stuff is
> supposed to making sure that everything is registered when we
> instantiate.

Ah, that makes sense. Thanks a lot for the info!

so long,

Hias

> 
> > same here, I don't get why the deferred probe stuff only deals with one of
> > the two options.
> 
> I think it's just an oversight - I think the change you were proposing
> to check the cpu_dai_name is a good idea anyway as it makes things more
> consistent and work more obviously by intention.  And more generally if
> we can simplify the code by removing legacy options that'd be good but
> that's a bigger bit of work...