[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f3aa01d9-7dc5-ded4-1a9a-07634afc0726@wanadoo.fr>
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);
>
Powered by blists - more mailing lists