linux-kernel - Re: [PATCH] ASoC: SOF: ipc4-topology: Use size

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:   Thu, 1 Jun 2023 19:57:13 +0200
From:   Christophe JAILLET <christophe.jaillet@...adoo.fr>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Peter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
        Bard Liao <yung-chuan.liao@...ux.intel.com>,
        Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
        Daniel Baluta <daniel.baluta@....com>,
        Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
        Mark Brown <broonie@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        Dan Carpenter <dan.carpenter@...cle.com>
Cc:     linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org,
        sound-open-firmware@...a-project.org, alsa-devel@...a-project.org
Subject: Re: [PATCH] ASoC: SOF: ipc4-topology: Use size_t for variable passed
 to kzalloc()

Le 01/06/2023 à 19:39, Pierre-Louis Bossart a écrit :
> 
> 
> On 6/1/23 12:30, Christophe JAILLET wrote:
>> struct_size() checks for overflow, but assigning its result to just a u32
>> may still overflow after a successful check.
>>
>> Use a size_t instead in order to be cleaner.
>>
>> Signed-off-by: Christophe JAILLET <christophe.jaillet@...adoo.fr>
>> ---
>> Based on analysis from Dan Carpenter on another patch (see [1]).
>>
>> [1]: https://lore.kernel.org/all/00e84595-e2c9-48ea-8737-18da34eaafbf@kili.mountain/
> 
> looks like there are similar cases of struct_size -> u32 conversions in
> other places:
> 
> struct snd_sof_control {
>      u32 size;	/* cdata size */
> 
> ipc3-topology.c:        scontrol->size = struct_size(cdata, chanv,
> scontrol->num_channels);
> ipc3-topology.c:        scontrol->size = struct_size(cdata, chanv,
> scontrol->num_channels);
> ipc4-topology.c:        scontrol->size = struct_size(control_data,
> chanv, scontrol->num_channels);

My coccinelle script does not handle such cases.

> 
> not sure how much of an issue this really is though?

I agree that in practice it should be safe as-is, but it can't hurt :).
I don't know this code well, but should [2] be part of the call chain, 
it is obvious that it CAN'T overflow.


I checked for places where such pattern occurs after Dan's comment on 
another patch. I'll see if I find better candidates.


CJ

[2]: 
https://elixir.bootlin.com/linux/v6.4-rc1/source/sound/soc/sof/topology.c#L1404

> 
>> ---
>>   sound/soc/sof/ipc4-topology.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/sound/soc/sof/ipc4-topology.c b/sound/soc/sof/ipc4-topology.c
>> index db64e0cb8663..50faa4c88b97 100644
>> --- a/sound/soc/sof/ipc4-topology.c
>> +++ b/sound/soc/sof/ipc4-topology.c
>> @@ -881,7 +881,7 @@ static int sof_ipc4_widget_setup_comp_process(struct snd_sof_widget *swidget)
>>   	/* allocate memory for base config extension if needed */
>>   	if (process->init_config == SOF_IPC4_MODULE_INIT_CONFIG_TYPE_BASE_CFG_WITH_EXT) {
>>   		struct sof_ipc4_base_module_cfg_ext *base_cfg_ext;
>> -		u32 ext_size = struct_size(base_cfg_ext, pin_formats,
>> +		size_t ext_size = struct_size(base_cfg_ext, pin_formats,
>>   						swidget->num_input_pins + swidget->num_output_pins);
>>   
>>   		base_cfg_ext = kzalloc(ext_size, GFP_KERNEL);
>