linux-kernel - Re: [alsa-devel] [PATCH v1 3/3] ASoC: soc-core: fix platform name vs. of

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: <a2068291-e554-cc4f-9af9-0022f3c4de34@nvidia.com>
Date:   Thu, 10 Jan 2019 10:56:35 +0000
From:   Jon Hunter <jonathanh@...dia.com>
To:     Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        Mark Brown <broonie@...nel.org>
CC:     Liam Girdwood <lgirdwood@...il.com>, <linux-tegra@...r.kernel.org>,
        Matthias Reichl <hias@...us.com>,
        <alsa-devel@...a-project.org>,
        Marcel Ziswiler <marcel.ziswiler@...adex.com>,
        Takashi Iwai <tiwai@...e.com>, <linux-kernel@...r.kernel.org>,
        Marcel Ziswiler <marcel@...wiler.com>
Subject: Re: [alsa-devel] [PATCH v1 3/3] ASoC: soc-core: fix platform name vs.
 of_node assignement

On 10/01/2019 01:16, Kuninori Morimoto wrote:

...

> As I mentioned above, I think we have same issue on codec side too.

Actually no. Looking at snd_soc_init_multicodec() it always allocates
memory if any of the 'legacy' codec members
(codec_name/codec_of_node/codec_dai_name) are populated. However, this
looks quite fragile to me and is susceptible to leaking memory if the
user/machine driver already incorrectly allocated the memory as well as
populating these legacy codec members.

My concern about all of this is it is not fool proof and hard to detect
if a machine driver is doing something bad that it should not.

> exchanging *platform to platform doesn't solve all issues.
> And we need to exchange all driver again if we had multi-platform
> support in the future (I don't know when it can happen though...)
> 
> My posted quick-patch can solve "dirty pointer" issue,
> but it can't solve "memory leak" issue.
> This issue will be solved if all driver can switch to
> modern style, but it needs more time.
> Are these correct ?
> 
> So, how about this ?

It is still fragile. Again the machine driver could have incorrectly set
these 'allocated_platform/codecs' members as they are exposed to the
machine driver. You have no way to determine if the machine driver is
doing the correct thing or not. The problem becomes more complex with
probe deferral.

Cheers
Jon

-- 
nvpublic