From: Chuck Lever <chuck.lever@oracle.com>
To: Gongwei Li <13875017792@163.com>,
trondmy@kernel.org, anna@kernel.org, jlayton@kernel.org
Cc: neil@brown.name, okorniev@redhat.com, Dai.Ngo@oracle.com,
tom@talpey.com, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
linux@treblig.org, ligongwei@kylinos.cn,
linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Kees Cook <kees@kernel.org>,
Jonathan Corbet <corbet@lwn.net>
Subject: Re: [PATCH 1/1] SUNRPC: use kmalloc_array() instead of kmalloc()
Date: Fri, 5 Dec 2025 09:46:25 -0500 [thread overview]
Message-ID: <85120c29-5b60-4d6b-9a90-e15637c57e1b@oracle.com> (raw)
In-Reply-To: <20251121030139.53241-1-13875017792@163.com>
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
prev parent reply other threads:[~2025-12-05 14:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-21 3:01 Gongwei Li
2025-12-05 14:46 ` Chuck Lever [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=85120c29-5b60-4d6b-9a90-e15637c57e1b@oracle.com \
--to=chuck.lever@oracle.com \
--cc=13875017792@163.com \
--cc=Dai.Ngo@oracle.com \
--cc=anna@kernel.org \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jlayton@kernel.org \
--cc=kees@kernel.org \
--cc=kuba@kernel.org \
--cc=ligongwei@kylinos.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux@treblig.org \
--cc=neil@brown.name \
--cc=netdev@vger.kernel.org \
--cc=okorniev@redhat.com \
--cc=pabeni@redhat.com \
--cc=tom@talpey.com \
--cc=trondmy@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®