linux-kernel - Re: [PATCH] init: 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] [day] [month] [year] [list]

Message-ID: <ccaa911b-f405-477e-a542-fe4f6bcb618d@gmail.com>
Date: Sat, 18 Oct 2025 18:13:35 +0100
From: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@...il.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: brauner@...nel.org, jack@...e.cz, linux-fsdevel@...r.kernel.org,
 linux-kernel@...r.kernel.org, skhan@...uxfoundation.org,
 david.hunter.linux@...il.com, linux-kernel-mentees@...ts.linuxfoundation.org
Subject: Re: [PATCH] init: Use kcalloc() instead of kzalloc()

On 10/3/25 11:40 AM, Mehdi Ben Hadj Khelifa wrote:
> On 10/2/25 3:36 AM, Al Viro wrote:
>> On Tue, Sep 30, 2025 at 09:35:37AM +0100, Mehdi Ben Hadj Khelifa wrote:
>>> Replace kzalloc() with kcalloc() in init/initramfs_test.c since the
>>> calculation inside kzalloc is dynamic and could overflow.
>>
>> Really?  Could you explain how
>>     a) ARRAY_SIZE(local variable) * (CPIO_HDRLEN + PATH_MAX + 3)
>> could possibly be dynamic and
> I missed that c is in local scope.It's already of size 3 and since 
> CPIO_HDRLEN is 110 and PATH_MAX is 4096 + 3, it's far from the limit and 
> it is calculated at compile time since all values are deducible.>     b) 
> just how large would that array have to be for it to "overflow"?
> If c could be of any size, it would have to be of size 1,020,310 for 32- 
> bit kernels and a lot for 64-bit kernels around 4.4 quadrillion 
> elements. Which is unrealistic.
> 
>> Incidentally, here the use of kcalloc would be unidiomatic - it's _not_
>> allocating an array of that many fixed-sized elements.  CPIO_HDRLEN +
>> PATH_MAX + 3 is not an element size - it's an upper bound on the amount
>> of space we might need for a single element.  Chunks of data generated
>> from array elements are placed into that buffer without any gaps -
>> it's really an array of bytes, large enough to fit all of them.
> Yes I get it now. But Even if the CPIO_HDRLEN + PATH_MAX + 3 is the 
> upper bound on the amount of space and in use it doesn't have any gaps 
> in memory, Shouldn't we change kzalloc() to kcalloc() since kzalloc() is 
> deprecated[1]?
> Regards,
> Mehdi Ben Hadj Khelifa
> 
> [1]:https://docs.kernel.org/process/deprecated.html

Hello viro,
I'm just resending reply in case if you missed it.

Best regards,
Mehdi Ben Hadj Khelifa