* [PATCH 1/1] SUNRPC: use kmalloc_array() instead of kmalloc()
@ 2025-11-21 3:01 Gongwei Li
2025-12-05 14:46 ` Chuck Lever
0 siblings, 1 reply; 2+ messages in thread
From: Gongwei Li @ 2025-11-21 3:01 UTC (permalink / raw)
To: trondmy, anna, chuck.lever, jlayton
Cc: neil, okorniev, Dai.Ngo, tom, davem, edumazet, kuba, pabeni,
horms, linux, ligongwei, linux-nfs, netdev, linux-kernel
From: Gongwei Li <ligongwei@kylinos.cn>
Replace kmalloc() with kmalloc_array() to prevent potential
overflow, as recommended in Documentation/process/deprecated.rst.
Signed-off-by: Gongwei Li <ligongwei@kylinos.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;
--
2.25.1
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH 1/1] SUNRPC: use kmalloc_array() instead of kmalloc()
2025-11-21 3:01 [PATCH 1/1] SUNRPC: use kmalloc_array() instead of kmalloc() Gongwei Li
@ 2025-12-05 14:46 ` Chuck Lever
0 siblings, 0 replies; 2+ messages in thread
From: Chuck Lever @ 2025-12-05 14:46 UTC (permalink / raw)
To: Gongwei Li, trondmy, anna, jlayton
Cc: neil, okorniev, Dai.Ngo, tom, davem, edumazet, kuba, pabeni,
horms, linux, ligongwei, linux-nfs, netdev, linux-kernel,
Kees Cook, Jonathan Corbet
On 11/20/25 10:01 PM, Gongwei Li wrote:
> From: Gongwei Li <ligongwei@kylinos.cn>
>
> Replace kmalloc() with kmalloc_array() to prevent potential
> overflow, as recommended in Documentation/process/deprecated.rst.
>
> Signed-off-by: Gongwei Li <ligongwei@kylinos.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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-12-05 14:47 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-11-21 3:01 [PATCH 1/1] SUNRPC: use kmalloc_array() instead of kmalloc() Gongwei Li
2025-12-05 14:46 ` Chuck Lever
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox