[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <85120c29-5b60-4d6b-9a90-e15637c57e1b@oracle.com>
Date: Fri, 5 Dec 2025 09:46:25 -0500
From: Chuck Lever <chuck.lever@...cle.com>
To: Gongwei Li <13875017792@....com>, trondmy@...nel.org, anna@...nel.org,
jlayton@...nel.org
Cc: neil@...wn.name, okorniev@...hat.com, Dai.Ngo@...cle.com, tom@...pey.com,
davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, horms@...nel.org, linux@...blig.org,
ligongwei@...inos.cn, linux-nfs@...r.kernel.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Kees Cook <kees@...nel.org>, Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH 1/1] SUNRPC: use kmalloc_array() instead of kmalloc()
On 11/20/25 10:01 PM, Gongwei Li wrote:
> From: Gongwei Li <ligongwei@...inos.cn>
>
> Replace kmalloc() with kmalloc_array() to prevent potential
> overflow, as recommended in Documentation/process/deprecated.rst.
>
> Signed-off-by: Gongwei Li <ligongwei@...inos.cn>
> ---
> net/sunrpc/auth_gss/gss_krb5_crypto.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sunrpc/auth_gss/gss_krb5_crypto.c b/net/sunrpc/auth_gss/gss_krb5_crypto.c
> index 16dcf115de1e..9418b1715317 100644
> --- a/net/sunrpc/auth_gss/gss_krb5_crypto.c
> +++ b/net/sunrpc/auth_gss/gss_krb5_crypto.c
> @@ -404,7 +404,7 @@ gss_krb5_cts_crypt(struct crypto_sync_skcipher *cipher, struct xdr_buf *buf,
> WARN_ON(0);
> return -ENOMEM;
> }
> - data = kmalloc(GSS_KRB5_MAX_BLOCKSIZE * 2, GFP_KERNEL);
> + data = kmalloc_array(2, GSS_KRB5_MAX_BLOCKSIZE, GFP_KERNEL);
> if (!data)
> return -ENOMEM;
>
The commit message's claim about "preventing potential overflow" is
technically misleading since no overflow was ever possible here.
1. GSS_KRB5_MAX_BLOCKSIZE is a compile-time constant (#define
GSS_KRB5_MAX_BLOCKSIZE (16))
2. The multiplication 2 * 16 = 32 is computed at compile time
3. There is no runtime variable involved, so overflow is already
impossible
kmalloc_array() is valuable when at least one operand is a runtime
variable (e.g., user-controlled count), but here both operands are
constants.
This appears to be a mechanical/automated cleanup patch that follows the
letter of the recommendation in the "open-coded arithmetic in allocator
arguments" section of Documentation/process/deprecated.rst without
considering whether the recommendation actually applies. The
deprecated.rst guidance about kmalloc_array() is specifically about
preventing overflow when array sizes are computed from runtime values
(although admittedly the text in deprecated.rst is not explicit about
this).
Aside from addressing an (impossible) overflow, is there another reason
to make this change that I might have missed?
--
Chuck Lever
Powered by blists - more mailing lists