linux-kernel - Re: [PATCH] regulator: bd718x7: Use kcalloc() instead of kzalloc()

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: <5d877bc4-f275-412f-a97f-47847dcad715@vivo.com>
Date: Mon, 18 Aug 2025 20:11:17 +0800
From: Qianfeng Rong <rongqianfeng@...o.com>
To: Matti Vaittinen <mazziesaccount@...il.com>,
 Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] regulator: bd718x7: Use kcalloc() instead of kzalloc()


在 2025/8/18 13:30, Matti Vaittinen 写道:
> On 17/08/2025 17:23, Qianfeng Rong wrote:
>> Replace calls of 'devm_kzalloc(dev, count * sizeof([type]), flags)'
>> with 'devm_kcalloc(dev, count, sizeof([type]), flags)' in
>> setup_feedback_loop() for safer memory allocation with built-in
>> overflow protection.
>>
>> Signed-off-by: Qianfeng Rong <rongqianfeng@...o.com>
>> ---
>>   drivers/regulator/bd718x7-regulator.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/regulator/bd718x7-regulator.c 
>> b/drivers/regulator/bd718x7-regulator.c
>> index e803cc59d68a..022d98f3c32a 100644
>> --- a/drivers/regulator/bd718x7-regulator.c
>> +++ b/drivers/regulator/bd718x7-regulator.c
>> @@ -1598,7 +1598,7 @@ static int setup_feedback_loop(struct device 
>> *dev, struct device_node *np,
>>           if (desc->n_linear_ranges && desc->linear_ranges) {
>>               struct linear_range *new;
>>   -            new = devm_kzalloc(dev, desc->n_linear_ranges *
>> +            new = devm_kcalloc(dev, desc->n_linear_ranges,
>>                          sizeof(struct linear_range),
>>                          GFP_KERNEL);
>>               if (!new)
>
> Thanks Qianfeng.
>
> I don't think this is particularly hazardous, because the 
> n_linear_ranges is known to be small. (It's populated in this same 
> file, with a size of pre-defined array). Still, this seems like a 
> valid change to me. I know some would say we should use sizeof(*new), 
> but I kind of like the sizeof(struct linear_range).


Thanks for taking the time to explain!

I also prefer sizeof(struct linear_range) to sizeof(*new) because it is 
more readable.  :)

>
> Reviewed-by: Matti Vaittinen <mazziesaccount@...il.com>
>
> Yours,
>     -- Matti
Best regards,
Qianfeng