linux-kernel - Re: out-of-bounds access in sound/soc/sof/topology.c

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] [day] [month] [year] [list]

Message-ID: <e349e9ca-7a4f-8d65-3ade-5ac4dfd5700a@linux.intel.com>
Date:   Wed, 27 Apr 2022 10:26:28 +0300
From:   Péter Ujfalusi <peter.ujfalusi@...ux.intel.com>
To:     Sergey Senozhatsky <senozhatsky@...omium.org>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc:     alsa-devel@...a-project.org,
        Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
        linux-kernel@...r.kernel.org,
        Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
        Takashi Iwai <tiwai@...e.com>,
        Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
        Mark Brown <broonie@...nel.org>,
        Ricardo Ribalda <ribalda@...omium.org>,
        Tomasz Figa <tfiga@...omium.org>,
        Jaska Uimonen <jaska.uimonen@...ux.intel.com>,
        sound-open-firmware@...a-project.org
Subject: Re: out-of-bounds access in sound/soc/sof/topology.c



On 27/04/2022 09:55, Sergey Senozhatsky wrote:
> On (22/04/19 08:07), Pierre-Louis Bossart wrote:
>>> Your analyzes are spot on, unfortunately. But...
>>>
>>> As of today, the sof_get_control_data() is in the call path of
>>> (ipc3-topology.c):
>>>
>>> sof_widget_update_ipc_comp_process() -> sof_process_load() ->
>>> sof_get_control_data()
>>>
>>> sof_widget_update_ipc_comp_process() is the ipc_setup callback for
>>> snd_soc_dapm_effect. If I'm not mistaken these only carries bin payload
>>> and never MIXER/ENUM/SWITCH/VOLUME.
>>> This means that the sof_get_control_data() is only called with
>>> SND_SOC_TPLG_TYPE_BYTES and for that the allocated data area is correct.
>>>
>>> This can explain why we have not seen any issues so far. This does not
>>> renders the code right, as how it is written atm is wrong.
>>
>>
>> Sergey's results with KASAN show that there's a real-life problem though. I also don't understand how that might happen.
>>
>> Could it be that these results are with a specific topology where our assumptions are incorrect?
> 
> Is there anything I can do to help?

I will send a patch shortly, I think it is going to be easy to backport
for you and test it.

-- 
Péter