Re: [PATCH 1/1] SUNRPC: use kmalloc_array() instead of kmalloc()
From: Chuck Lever <hidden>
Date: 2025-12-05 14:47:03
Also in:
linux-nfs, lkml
On 11/20/25 10:01 PM, Gongwei Li wrote:
quoted hunk ↗ jump to hunk
From: Gongwei Li <redacted> Replace kmalloc() with kmalloc_array() to prevent potential overflow, as recommended in Documentation/process/deprecated.rst. Signed-off-by: Gongwei Li <redacted> --- 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