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 <[email protected]>
---
Based on analysis from Dan Carpenter on another patch (see [1]).
[1]: https://lore.kernel.org/all/[email protected]/
---
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);
--
2.34.1
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 <[email protected]>
> ---
> Based on analysis from Dan Carpenter on another patch (see [1]).
>
> [1]: https://lore.kernel.org/all/[email protected]/
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);
not sure how much of an issue this really is though?
> ---
> 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);
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 <[email protected]>
>> ---
>> Based on analysis from Dan Carpenter on another patch (see [1]).
>>
>> [1]: https://lore.kernel.org/all/[email protected]/
>
> 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);
>
On Thu, Jun 01, 2023 at 07:30:12PM +0200, 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 <[email protected]>
> ---
> Based on analysis from Dan Carpenter on another patch (see [1]).
>
> [1]: https://lore.kernel.org/all/[email protected]/
> ---
> 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);
The temptation would be to change the addition as well:
size_t ext_size = struct_size(base_cfg_ext, pin_formats,
size_add(swidget->num_input_pins, swidget->num_output_pins);
These values can only be in the 0-8 range so it's not a real bug.
Smatch cannot parse this data correctly to verify that it is safe.
Maybe in two years Smatch will be able to. Probably a human who is
unfamiliar with this code can figure out that it is safe within 15
minutes?
I think the change to size_t doesn't hurt anyone and there isn't any
downside to it. The size_add() change is slightly less readable than
just adding the numbers but I think eventually people will just get used
to it.
regards,
dan carpenter