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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ