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: <b0388977-413c-46d0-b0e1-fc8d26ef9323@gmail.com>
Date: Fri, 3 Oct 2025 11:40:17 +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/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