[PATCH libcrypto 1/2] array_size: introduce min_array_size() function decoration

[PATCH libcrypto 1/2] array_size: introduce min_array_size() function decoration

[Jason A. Donenfeld]

Clang and recent gcc support warning if they are able to prove that the
user is passing to a function an array that is too short in size. For
example:

    void blah(unsigned char herp[static 7]);
    static void schma(void)
    {
        unsigned char good[] = { 1, 2, 3, 4, 5, 6, 7 };
        unsigned char bad[] = { 1, 2, 3, 4, 5, 6 };
        blah(good);
        blah(bad);
    }

The notation here, `static 7`, means that it's incorrect to pass
anything less than 7 elements. This is section 6.7.5.3 of C99:

    If the keyword static also appears within the [ and ] of the array
    type derivation, then for each call to the function, the value of
    the corresponding actual argument shall provide access to the first
    element of an array with at least as many elements as specified by
    the size expression.

Here is the output from gcc 15:

    zx2c4@thinkpad /tmp $ gcc -c a.c
    a.c: In function ‘schma’:
    a.c:9:9: warning: ‘blah’ accessing 7 bytes in a region of size 6 [-Wstringop-overflow=]
        9 |         blah(bad);
          |         ^~~~~~~~~
    a.c:9:9: note: referencing argument 1 of type ‘unsigned char[7]’
    a.c:2:6: note: in a call to function ‘blah’
        2 | void blah(unsigned char herp[static 7]);
          |      ^~~~

And from clang 21:

    zx2c4@thinkpad /tmp $ clang -c a.c
    a.c:9:2: warning: array argument is too small; contains 6 elements, callee requires at least 7
          [-Warray-bounds]
        9 |         blah(bad);
          |         ^    ~~~
    a.c:2:25: note: callee declares array parameter as static here
        2 | void blah(unsigned char herp[static 7]);
          |                         ^   ~~~~~~~~~~
    1 warning generated.

So these are covered by, variously, -Wstringop-overflow and
-Warray-bounds.

Introduce min_array_size(), so that the above code becomes slightly less
ugly:

    void blah(unsigned char herp[min_array_size(7)]);

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
 include/linux/array_size.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/include/linux/array_size.h b/include/linux/array_size.h
index 06d7d83196ca..8671aee11479 100644
--- a/include/linux/array_size.h
+++ b/include/linux/array_size.h
@@ -10,4 +10,11 @@
  */
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
 
+/**
+ * min_array_size - parameter decoration to hint to the compiler that the
+ *                  passed array should have at least @n elements
+ * @n: minimum number of elements, after which the compiler may warn
+ */
+#define min_array_size(n) static n
+
 #endif  /* _LINUX_ARRAY_SIZE_H */
-- 
2.51.2

[PATCH libcrypto 2/2] crypto: chacha20poly1305: statically check fixed array lengths

[Jason A. Donenfeld]

Several parameters of the chacha20poly1305 functions require arrays of
an exact length. Use the new min_array_size() macro to instruct gcc and
clang to statically check that the caller is passing an object of at
least that length.

Here it is in action, with this faulty patch:

diff --git a/drivers/net/wireguard/cookie.h b/drivers/net/wireguard/cookie.h
index c4bd61ca03f2..2839c46029f8 100644
--- a/drivers/net/wireguard/cookie.h
+++ b/drivers/net/wireguard/cookie.h
@@ -13,7 +13,7 @@ struct wg_peer;

 struct cookie_checker {
 	u8 secret[NOISE_HASH_LEN];
-	u8 cookie_encryption_key[NOISE_SYMMETRIC_KEY_LEN];
+	u8 cookie_encryption_key[NOISE_SYMMETRIC_KEY_LEN - 1];
 	u8 message_mac1_key[NOISE_SYMMETRIC_KEY_LEN];
 	u64 secret_birthdate;
 	struct rw_semaphore secret_lock;

If I try compiling this code, I get this nasty warning:

  CC      drivers/net/wireguard/cookie.o
drivers/net/wireguard/cookie.c: In function ‘wg_cookie_message_create’:
drivers/net/wireguard/cookie.c:193:9: warning: ‘xchacha20poly1305_encrypt’ reading 32 bytes from a region of size 31 [-Wstringop-overread]
  193 |         xchacha20poly1305_encrypt(dst->encrypted_cookie, cookie, COOKIE_LEN,
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  194 |                                   macs->mac1, COOKIE_LEN, dst->nonce,
      |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  195 |                                   checker->cookie_encryption_key);
      |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireguard/cookie.c:193:9: note: referencing argument 7 of type ‘const u8 *’ {aka ‘const unsigned char *’}
In file included from drivers/net/wireguard/messages.h:10,
                 from drivers/net/wireguard/cookie.h:9,
                 from drivers/net/wireguard/cookie.c:6:
include/crypto/chacha20poly1305.h:29:6: note: in a call to function ‘xchacha20poly1305_encrypt’
   29 | void xchacha20poly1305_encrypt(u8 *dst, const u8 *src, const size_t src_len,
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~

This is exactly what's expected.

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
 include/crypto/chacha20poly1305.h | 17 +++++++++--------
 lib/crypto/chacha20poly1305.c     | 18 +++++++++---------
 2 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/include/crypto/chacha20poly1305.h b/include/crypto/chacha20poly1305.h
index d2ac3ff7dc1e..b19975f07d2f 100644
--- a/include/crypto/chacha20poly1305.h
+++ b/include/crypto/chacha20poly1305.h
@@ -6,6 +6,7 @@
 #ifndef __CHACHA20POLY1305_H
 #define __CHACHA20POLY1305_H
 
+#include <linux/array_size.h>
 #include <linux/types.h>
 #include <linux/scatterlist.h>
 
@@ -18,32 +19,32 @@ enum chacha20poly1305_lengths {
 void chacha20poly1305_encrypt(u8 *dst, const u8 *src, const size_t src_len,
 			      const u8 *ad, const size_t ad_len,
 			      const u64 nonce,
-			      const u8 key[CHACHA20POLY1305_KEY_SIZE]);
+			      const u8 key[min_array_size(CHACHA20POLY1305_KEY_SIZE)]);
 
 bool __must_check
 chacha20poly1305_decrypt(u8 *dst, const u8 *src, const size_t src_len,
 			 const u8 *ad, const size_t ad_len, const u64 nonce,
-			 const u8 key[CHACHA20POLY1305_KEY_SIZE]);
+			 const u8 key[min_array_size(CHACHA20POLY1305_KEY_SIZE)]);
 
 void xchacha20poly1305_encrypt(u8 *dst, const u8 *src, const size_t src_len,
 			       const u8 *ad, const size_t ad_len,
-			       const u8 nonce[XCHACHA20POLY1305_NONCE_SIZE],
-			       const u8 key[CHACHA20POLY1305_KEY_SIZE]);
+			       const u8 nonce[min_array_size(XCHACHA20POLY1305_NONCE_SIZE)],
+			       const u8 key[min_array_size(CHACHA20POLY1305_KEY_SIZE)]);
 
 bool __must_check xchacha20poly1305_decrypt(
 	u8 *dst, const u8 *src, const size_t src_len, const u8 *ad,
-	const size_t ad_len, const u8 nonce[XCHACHA20POLY1305_NONCE_SIZE],
-	const u8 key[CHACHA20POLY1305_KEY_SIZE]);
+	const size_t ad_len, const u8 nonce[min_array_size(XCHACHA20POLY1305_NONCE_SIZE)],
+	const u8 key[min_array_size(CHACHA20POLY1305_KEY_SIZE)]);
 
 bool chacha20poly1305_encrypt_sg_inplace(struct scatterlist *src, size_t src_len,
 					 const u8 *ad, const size_t ad_len,
 					 const u64 nonce,
-					 const u8 key[CHACHA20POLY1305_KEY_SIZE]);
+					 const u8 key[min_array_size(CHACHA20POLY1305_KEY_SIZE)]);
 
 bool chacha20poly1305_decrypt_sg_inplace(struct scatterlist *src, size_t src_len,
 					 const u8 *ad, const size_t ad_len,
 					 const u64 nonce,
-					 const u8 key[CHACHA20POLY1305_KEY_SIZE]);
+					 const u8 key[min_array_size(CHACHA20POLY1305_KEY_SIZE)]);
 
 bool chacha20poly1305_selftest(void);
 
diff --git a/lib/crypto/chacha20poly1305.c b/lib/crypto/chacha20poly1305.c
index 0b49d6aedefd..5916d3bb694c 100644
--- a/lib/crypto/chacha20poly1305.c
+++ b/lib/crypto/chacha20poly1305.c
@@ -89,7 +89,7 @@ __chacha20poly1305_encrypt(u8 *dst, const u8 *src, const size_t src_len,
 void chacha20poly1305_encrypt(u8 *dst, const u8 *src, const size_t src_len,
 			      const u8 *ad, const size_t ad_len,
 			      const u64 nonce,
-			      const u8 key[CHACHA20POLY1305_KEY_SIZE])
+			      const u8 key[min_array_size(CHACHA20POLY1305_KEY_SIZE)])
 {
 	struct chacha_state chacha_state;
 	u32 k[CHACHA_KEY_WORDS];
@@ -111,8 +111,8 @@ EXPORT_SYMBOL(chacha20poly1305_encrypt);
 
 void xchacha20poly1305_encrypt(u8 *dst, const u8 *src, const size_t src_len,
 			       const u8 *ad, const size_t ad_len,
-			       const u8 nonce[XCHACHA20POLY1305_NONCE_SIZE],
-			       const u8 key[CHACHA20POLY1305_KEY_SIZE])
+			       const u8 nonce[min_array_size(XCHACHA20POLY1305_NONCE_SIZE)],
+			       const u8 key[min_array_size(CHACHA20POLY1305_KEY_SIZE)])
 {
 	struct chacha_state chacha_state;
 
@@ -170,7 +170,7 @@ __chacha20poly1305_decrypt(u8 *dst, const u8 *src, const size_t src_len,
 bool chacha20poly1305_decrypt(u8 *dst, const u8 *src, const size_t src_len,
 			      const u8 *ad, const size_t ad_len,
 			      const u64 nonce,
-			      const u8 key[CHACHA20POLY1305_KEY_SIZE])
+			      const u8 key[min_array_size(CHACHA20POLY1305_KEY_SIZE)])
 {
 	struct chacha_state chacha_state;
 	u32 k[CHACHA_KEY_WORDS];
@@ -195,8 +195,8 @@ EXPORT_SYMBOL(chacha20poly1305_decrypt);
 
 bool xchacha20poly1305_decrypt(u8 *dst, const u8 *src, const size_t src_len,
 			       const u8 *ad, const size_t ad_len,
-			       const u8 nonce[XCHACHA20POLY1305_NONCE_SIZE],
-			       const u8 key[CHACHA20POLY1305_KEY_SIZE])
+			       const u8 nonce[min_array_size(XCHACHA20POLY1305_NONCE_SIZE)],
+			       const u8 key[min_array_size(CHACHA20POLY1305_KEY_SIZE)])
 {
 	struct chacha_state chacha_state;
 
@@ -211,7 +211,7 @@ bool chacha20poly1305_crypt_sg_inplace(struct scatterlist *src,
 				       const size_t src_len,
 				       const u8 *ad, const size_t ad_len,
 				       const u64 nonce,
-				       const u8 key[CHACHA20POLY1305_KEY_SIZE],
+				       const u8 key[min_array_size(CHACHA20POLY1305_KEY_SIZE)],
 				       int encrypt)
 {
 	const u8 *pad0 = page_address(ZERO_PAGE(0));
@@ -335,7 +335,7 @@ bool chacha20poly1305_crypt_sg_inplace(struct scatterlist *src,
 bool chacha20poly1305_encrypt_sg_inplace(struct scatterlist *src, size_t src_len,
 					 const u8 *ad, const size_t ad_len,
 					 const u64 nonce,
-					 const u8 key[CHACHA20POLY1305_KEY_SIZE])
+					 const u8 key[min_array_size(CHACHA20POLY1305_KEY_SIZE)])
 {
 	return chacha20poly1305_crypt_sg_inplace(src, src_len, ad, ad_len,
 						 nonce, key, 1);
@@ -345,7 +345,7 @@ EXPORT_SYMBOL(chacha20poly1305_encrypt_sg_inplace);
 bool chacha20poly1305_decrypt_sg_inplace(struct scatterlist *src, size_t src_len,
 					 const u8 *ad, const size_t ad_len,
 					 const u64 nonce,
-					 const u8 key[CHACHA20POLY1305_KEY_SIZE])
+					 const u8 key[min_array_size(CHACHA20POLY1305_KEY_SIZE)])
 {
 	if (unlikely(src_len < POLY1305_DIGEST_SIZE))
 		return false;
-- 
2.51.2

Re: [PATCH libcrypto 1/2] array_size: introduce min_array_size() function decoration

[Eric Biggers]

On Tue, Nov 18, 2025 at 06:02:39PM +0100, Jason A. Donenfeld wrote:
> diff --git a/include/linux/array_size.h b/include/linux/array_size.h
> index 06d7d83196ca..8671aee11479 100644
> --- a/include/linux/array_size.h
> +++ b/include/linux/array_size.h

I think compiler.h would be a better place?

> @@ -10,4 +10,11 @@
>   */
>  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
>  
> +/**
> + * min_array_size - parameter decoration to hint to the compiler that the
> + *                  passed array should have at least @n elements
> + * @n: minimum number of elements, after which the compiler may warn
> + */
> +#define min_array_size(n) static n

"after which" => "below which"

Anyway, I actually have a slight preference for just using 'static n'
directly, without the unnecessary min_array_size() wrapper.  But if
other people prefer min_array_size(), that's fine with me too.  At least
this is what Linus asked for
(https://lore.kernel.org/linux-crypto/CAHk-=wj6J5L5Y+oHc-i9BrDONpSbtt=iEemcyUm3dYnZ3pXxxg@mail.gmail.com/).

- Eric

Re: [PATCH libcrypto 1/2] array_size: introduce min_array_size() function decoration

[Jason A. Donenfeld]

On Tue, Nov 18, 2025 at 03:24:35PM -0800, Eric Biggers wrote:
> On Tue, Nov 18, 2025 at 06:02:39PM +0100, Jason A. Donenfeld wrote:
> > diff --git a/include/linux/array_size.h b/include/linux/array_size.h
> > index 06d7d83196ca..8671aee11479 100644
> > --- a/include/linux/array_size.h
> > +++ b/include/linux/array_size.h
> 
> I think compiler.h would be a better place?

That was my initial idea, but then I saw that array_size.h got split
out, and this seemed be on the topic...

> 
> > @@ -10,4 +10,11 @@
> >   */
> >  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
> >  
> > +/**
> > + * min_array_size - parameter decoration to hint to the compiler that the
> > + *                  passed array should have at least @n elements
> > + * @n: minimum number of elements, after which the compiler may warn
> > + */
> > +#define min_array_size(n) static n
> 
> "after which" => "below which"

Er, thanks.

> 
> Anyway, I actually have a slight preference for just using 'static n'
> directly, without the unnecessary min_array_size() wrapper.  But if
> other people prefer min_array_size(), that's fine with me too.  At least
> this is what Linus asked for
> (https://lore.kernel.org/linux-crypto/CAHk-=wj6J5L5Y+oHc-i9BrDONpSbtt=iEemcyUm3dYnZ3pXxxg@mail.gmail.com/).

There's also this other approach from 2001 that the C committee I guess
shot down: https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_205.htm
It is basically:

    #define __at_least static

We could attempt to do the same with `at_least`...

It kind of feels like we're just inventing a language at that point
though.

Jason

Re: [PATCH libcrypto 1/2] array_size: introduce min_array_size() function decoration

[Linus Torvalds]

On Tue, 18 Nov 2025 at 15:24, Eric Biggers <ebiggers@kernel.org> wrote:
>
> Anyway, I actually have a slight preference for just using 'static n'
> directly, without the unnecessary min_array_size() wrapper.  But if
> other people prefer min_array_size(), that's fine with me too.  At least
> this is what Linus asked for
> (https://lore.kernel.org/linux-crypto/CAHk-=wj6J5L5Y+oHc-i9BrDONpSbtt=iEemcyUm3dYnZ3pXxxg@mail.gmail.com/).

I wouldn't call that "asked for".

It was more a musing on how random that "static" syntax is and it's
likely incomprehensible to a lot of people - but also pointing out
that we already do have users of it, and saying that maybe it won't be
incomprehensible once we have a lot of users.

So I'm definitely not pushing for it.

But I do suspect it makes people understand what the code does more...

            Linus

Re: [PATCH libcrypto 2/2] crypto: chacha20poly1305: statically check fixed array lengths

[kernel test robot]

Hi Jason,

kernel test robot noticed the following build warnings:

[auto build test WARNING on herbert-cryptodev-2.6/master]
[also build test WARNING on herbert-crypto-2.6/master ebiggers/libcrypto-next ebiggers/libcrypto-fixes linus/master linux/master v6.18-rc6 next-20251119]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Jason-A-Donenfeld/crypto-chacha20poly1305-statically-check-fixed-array-lengths/20251119-011125
base:   https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
patch link:    https://lore.kernel.org/r/20251118170240.689299-2-Jason%40zx2c4.com
patch subject: [PATCH libcrypto 2/2] crypto: chacha20poly1305: statically check fixed array lengths
config: m68k-defconfig (https://download.01.org/0day-ci/archive/20251119/202511191846.AAKP7VQw-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 15.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251119/202511191846.AAKP7VQw-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202511191846.AAKP7VQw-lkp@intel.com/

All warnings (new ones prefixed by >>):

   drivers/net/wireguard/cookie.c: In function 'wg_cookie_message_create':
>> drivers/net/wireguard/cookie.c:193:9: warning: 'xchacha20poly1305_encrypt' reading 32 bytes from a region of size 31 [-Wstringop-overread]
     193 |         xchacha20poly1305_encrypt(dst->encrypted_cookie, cookie, COOKIE_LEN,
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     194 |                                   macs->mac1, COOKIE_LEN, dst->nonce,
         |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     195 |                                   checker->cookie_encryption_key);
         |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/wireguard/cookie.c:193:9: note: referencing argument 7 of type 'const u8[32]' {aka 'const unsigned char[32]'}
   In file included from drivers/net/wireguard/messages.h:10,
                    from drivers/net/wireguard/cookie.h:9,
                    from drivers/net/wireguard/cookie.c:6:
   include/crypto/chacha20poly1305.h:29:6: note: in a call to function 'xchacha20poly1305_encrypt'
      29 | void xchacha20poly1305_encrypt(u8 *dst, const u8 *src, const size_t src_len,
         |      ^~~~~~~~~~~~~~~~~~~~~~~~~


vim +/xchacha20poly1305_encrypt +193 drivers/net/wireguard/cookie.c

e7096c131e5161f Jason A. Donenfeld 2019-12-09  179  
e7096c131e5161f Jason A. Donenfeld 2019-12-09  180  void wg_cookie_message_create(struct message_handshake_cookie *dst,
e7096c131e5161f Jason A. Donenfeld 2019-12-09  181  			      struct sk_buff *skb, __le32 index,
e7096c131e5161f Jason A. Donenfeld 2019-12-09  182  			      struct cookie_checker *checker)
e7096c131e5161f Jason A. Donenfeld 2019-12-09  183  {
e7096c131e5161f Jason A. Donenfeld 2019-12-09  184  	struct message_macs *macs = (struct message_macs *)
e7096c131e5161f Jason A. Donenfeld 2019-12-09  185  		((u8 *)skb->data + skb->len - sizeof(*macs));
e7096c131e5161f Jason A. Donenfeld 2019-12-09  186  	u8 cookie[COOKIE_LEN];
e7096c131e5161f Jason A. Donenfeld 2019-12-09  187  
e7096c131e5161f Jason A. Donenfeld 2019-12-09  188  	dst->header.type = cpu_to_le32(MESSAGE_HANDSHAKE_COOKIE);
e7096c131e5161f Jason A. Donenfeld 2019-12-09  189  	dst->receiver_index = index;
e7096c131e5161f Jason A. Donenfeld 2019-12-09  190  	get_random_bytes_wait(dst->nonce, COOKIE_NONCE_LEN);
e7096c131e5161f Jason A. Donenfeld 2019-12-09  191  
e7096c131e5161f Jason A. Donenfeld 2019-12-09  192  	make_cookie(cookie, skb, checker);
e7096c131e5161f Jason A. Donenfeld 2019-12-09 @193  	xchacha20poly1305_encrypt(dst->encrypted_cookie, cookie, COOKIE_LEN,
e7096c131e5161f Jason A. Donenfeld 2019-12-09  194  				  macs->mac1, COOKIE_LEN, dst->nonce,
e7096c131e5161f Jason A. Donenfeld 2019-12-09  195  				  checker->cookie_encryption_key);
e7096c131e5161f Jason A. Donenfeld 2019-12-09  196  }
e7096c131e5161f Jason A. Donenfeld 2019-12-09  197  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH libcrypto 2/2] crypto: chacha20poly1305: statically check fixed array lengths

[kernel test robot]

Hi Jason,

kernel test robot noticed the following build warnings:

[auto build test WARNING on herbert-cryptodev-2.6/master]
[also build test WARNING on herbert-crypto-2.6/master ebiggers/libcrypto-next ebiggers/libcrypto-fixes linus/master linux/master v6.18-rc6 next-20251119]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Jason-A-Donenfeld/crypto-chacha20poly1305-statically-check-fixed-array-lengths/20251119-011125
base:   https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
patch link:    https://lore.kernel.org/r/20251118170240.689299-2-Jason%40zx2c4.com
patch subject: [PATCH libcrypto 2/2] crypto: chacha20poly1305: statically check fixed array lengths
config: loongarch-allmodconfig (https://download.01.org/0day-ci/archive/20251119/202511192000.TLYrcg0Z-lkp@intel.com/config)
compiler: clang version 19.1.7 (https://github.com/llvm/llvm-project cd708029e0b2869e80abe31ddb175f7c35361f90)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251119/202511192000.TLYrcg0Z-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202511192000.TLYrcg0Z-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> drivers/net/wireguard/cookie.c:193:2: warning: array argument is too small; contains 31 elements, callee requires at least 32 [-Warray-bounds]
     193 |         xchacha20poly1305_encrypt(dst->encrypted_cookie, cookie, COOKIE_LEN,
         |         ^
     194 |                                   macs->mac1, COOKIE_LEN, dst->nonce,
     195 |                                   checker->cookie_encryption_key);
         |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/crypto/chacha20poly1305.h:32:20: note: callee declares array parameter as static here
      32 |                                const u8 key[min_array_size(CHACHA20POLY1305_KEY_SIZE)]);
         |                                         ^  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   In file included from drivers/net/wireguard/cookie.c:6:
   In file included from drivers/net/wireguard/cookie.h:9:
   In file included from drivers/net/wireguard/messages.h:10:
   In file included from include/crypto/chacha20poly1305.h:11:
   In file included from include/linux/scatterlist.h:5:
   In file included from include/linux/string.h:382:
   include/linux/fortify-string.h:480:4: warning: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning]
     480 |                         __write_overflow_field(p_size_field, size);
         |                         ^
   2 warnings generated.


vim +193 drivers/net/wireguard/cookie.c

e7096c131e5161 Jason A. Donenfeld 2019-12-09  179  
e7096c131e5161 Jason A. Donenfeld 2019-12-09  180  void wg_cookie_message_create(struct message_handshake_cookie *dst,
e7096c131e5161 Jason A. Donenfeld 2019-12-09  181  			      struct sk_buff *skb, __le32 index,
e7096c131e5161 Jason A. Donenfeld 2019-12-09  182  			      struct cookie_checker *checker)
e7096c131e5161 Jason A. Donenfeld 2019-12-09  183  {
e7096c131e5161 Jason A. Donenfeld 2019-12-09  184  	struct message_macs *macs = (struct message_macs *)
e7096c131e5161 Jason A. Donenfeld 2019-12-09  185  		((u8 *)skb->data + skb->len - sizeof(*macs));
e7096c131e5161 Jason A. Donenfeld 2019-12-09  186  	u8 cookie[COOKIE_LEN];
e7096c131e5161 Jason A. Donenfeld 2019-12-09  187  
e7096c131e5161 Jason A. Donenfeld 2019-12-09  188  	dst->header.type = cpu_to_le32(MESSAGE_HANDSHAKE_COOKIE);
e7096c131e5161 Jason A. Donenfeld 2019-12-09  189  	dst->receiver_index = index;
e7096c131e5161 Jason A. Donenfeld 2019-12-09  190  	get_random_bytes_wait(dst->nonce, COOKIE_NONCE_LEN);
e7096c131e5161 Jason A. Donenfeld 2019-12-09  191  
e7096c131e5161 Jason A. Donenfeld 2019-12-09  192  	make_cookie(cookie, skb, checker);
e7096c131e5161 Jason A. Donenfeld 2019-12-09 @193  	xchacha20poly1305_encrypt(dst->encrypted_cookie, cookie, COOKIE_LEN,
e7096c131e5161 Jason A. Donenfeld 2019-12-09  194  				  macs->mac1, COOKIE_LEN, dst->nonce,
e7096c131e5161 Jason A. Donenfeld 2019-12-09  195  				  checker->cookie_encryption_key);
e7096c131e5161 Jason A. Donenfeld 2019-12-09  196  }
e7096c131e5161 Jason A. Donenfeld 2019-12-09  197  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH libcrypto 2/2] crypto: chacha20poly1305: statically check fixed array lengths

[Linus Torvalds]

 On Wed, 19 Nov 2025 at 04:46, kernel test robot <lkp@intel.com> wrote:
>
> >> drivers/net/wireguard/cookie.c:193:2: warning: array argument is too small; contains 31 elements, callee requires at least 32 [-Warray-bounds]

Hmm. Is this a compiler bug?

That checker->cookie_encryption_key is declared as

        u8 cookie_encryption_key[NOISE_SYMMETRIC_KEY_LEN];

and NOISE_SYMMETRIC_KEY_LEN is an enum that is defined to be the same
as CHACHA20POLY1305_KEY_SIZE, which is 32.

And the compiler is aware of that:

>    include/crypto/chacha20poly1305.h:32:20: note: callee declares array parameter as static here
>       32 |                                const u8 key[min_array_size(CHACHA20POLY1305_KEY_SIZE)]);
>          |                                         ^  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

but still talks about "contains 31 elements".

Is this some confusion with the compiler thinking that a "const u8[]"
is a string, and then at some point subtracted one as the max length,
and then is confused due to that?

Because if compilers screw this up, we can't do that 'static' thing,
regardless of name. I'm  not willing to play silly buggers with broken
compiler warnings.

               Linus

Re: [PATCH libcrypto 2/2] crypto: chacha20poly1305: statically check fixed array lengths

[Jason A. Donenfeld]

Hey Linus,

On Wed, Nov 19, 2025 at 5:29 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>  On Wed, 19 Nov 2025 at 04:46, kernel test robot <lkp@intel.com> wrote:
> >
> > >> drivers/net/wireguard/cookie.c:193:2: warning: array argument is too small; contains 31 elements, callee requires at least 32 [-Warray-bounds]
>
> Hmm. Is this a compiler bug?

It's not. It's a 0day test bot bug! My original patch had in it some
commentary about what a bug would look like when it's caught by the
compiler. In order to provoke that compiler output, I mentioned in the
commit message that this diff will produce such and such result:

diff --git a/drivers/net/wireguard/cookie.h b/drivers/net/wireguard/cookie.h
index c4bd61ca03f2..2839c46029f8 100644
--- a/drivers/net/wireguard/cookie.h
+++ b/drivers/net/wireguard/cookie.h
@@ -13,7 +13,7 @@ struct wg_peer;

 struct cookie_checker {
        u8 secret[NOISE_HASH_LEN];
-       u8 cookie_encryption_key[NOISE_SYMMETRIC_KEY_LEN];
+       u8 cookie_encryption_key[NOISE_SYMMETRIC_KEY_LEN - 1];
        u8 message_mac1_key[NOISE_SYMMETRIC_KEY_LEN];
        u64 secret_birthdate;
        struct rw_semaphore secret_lock;

It looks like the 0day test bot just went through the email and
applied all the `diff --git ...` hunks, without taking into account
the context area above where the actual patches start.

So, if anything, this test bot output is showing that the compiler
feature works as intended.

Jason

Re: [PATCH libcrypto 2/2] crypto: chacha20poly1305: statically check fixed array lengths

[Linus Torvalds]

On Wed, 19 Nov 2025 at 08:47, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> > Hmm. Is this a compiler bug?
>
> It's not. It's a 0day test bot bug! My original patch had in it some
> commentary about what a bug would look like when it's caught by the
> compiler. In order to provoke that compiler output, I mentioned in the
> commit message that this diff will produce such and such result:

Lol, ok.

I sometimes actively just whitespace-damage my "what about this"
patches to make sure people don't just blindly apply them without
thinking about them and actually look at them.

Maybe that's a good policy in general, so that the bots don't do the same ;)

            Linus

Re: [PATCH libcrypto 2/2] crypto: chacha20poly1305: statically check fixed array lengths

[Nathan Chancellor]

On Wed, Nov 19, 2025 at 05:46:44PM +0100, Jason A. Donenfeld wrote:
> Hey Linus,
> 
> On Wed, Nov 19, 2025 at 5:29 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> >  On Wed, 19 Nov 2025 at 04:46, kernel test robot <lkp@intel.com> wrote:
> > >
> > > >> drivers/net/wireguard/cookie.c:193:2: warning: array argument is too small; contains 31 elements, callee requires at least 32 [-Warray-bounds]
> >
> > Hmm. Is this a compiler bug?
> 
> It's not. It's a 0day test bot bug! My original patch had in it some
> commentary about what a bug would look like when it's caught by the
> compiler. In order to provoke that compiler output, I mentioned in the
> commit message that this diff will produce such and such result:
> 
> diff --git a/drivers/net/wireguard/cookie.h b/drivers/net/wireguard/cookie.h
> index c4bd61ca03f2..2839c46029f8 100644
> --- a/drivers/net/wireguard/cookie.h
> +++ b/drivers/net/wireguard/cookie.h
> @@ -13,7 +13,7 @@ struct wg_peer;
> 
>  struct cookie_checker {
>         u8 secret[NOISE_HASH_LEN];
> -       u8 cookie_encryption_key[NOISE_SYMMETRIC_KEY_LEN];
> +       u8 cookie_encryption_key[NOISE_SYMMETRIC_KEY_LEN - 1];
>         u8 message_mac1_key[NOISE_SYMMETRIC_KEY_LEN];
>         u64 secret_birthdate;
>         struct rw_semaphore secret_lock;
> 
> It looks like the 0day test bot just went through the email and
> applied all the `diff --git ...` hunks, without taking into account
> the context area above where the actual patches start.

I don't think it is a bot issue. Just running 'b4 shazam' (i.e. just
applying the patch with 'git am') on the series results in:

commit 6ddc87109d4bb589d02cc3a8b037c99fdc4cbbf9
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Nov 18 18:02:40 2025 +0100

    crypto: chacha20poly1305: statically check fixed array lengths
    
    Several parameters of the chacha20poly1305 functions require arrays of
    an exact length. Use the new min_array_size() macro to instruct gcc and
    clang to statically check that the caller is passing an object of at
    least that length.
    
    Here it is in action, with this faulty patch:

diff --git a/drivers/net/wireguard/cookie.h b/drivers/net/wireguard/cookie.h
index c4bd61ca03f2..2839c46029f8 100644
--- a/drivers/net/wireguard/cookie.h
+++ b/drivers/net/wireguard/cookie.h
@@ -13,7 +13,7 @@ struct wg_peer;
 
 struct cookie_checker {
 	u8 secret[NOISE_HASH_LEN];
-	u8 cookie_encryption_key[NOISE_SYMMETRIC_KEY_LEN];
+	u8 cookie_encryption_key[NOISE_SYMMETRIC_KEY_LEN - 1];
 	u8 message_mac1_key[NOISE_SYMMETRIC_KEY_LEN];
 	u64 secret_birthdate;
 	struct rw_semaphore secret_lock;

followed by the rest of the patch for me.

Cheers,
Nathan

Re: [PATCH libcrypto 1/2] array_size: introduce min_array_size() function decoration

[Jason A. Donenfeld]

On Wed, Nov 19, 2025 at 12:31:11AM +0100, Jason A. Donenfeld wrote:
> There's also this other approach from 2001 that the C committee I guess
> shot down: https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_205.htm
> It is basically:
> 
>     #define __at_least static
> 
> We could attempt to do the same with `at_least`...
> 
> It kind of feels like we're just inventing a language at that point
> though.

Actually, you know, the more this apparently terrible idea sits in my
head, the more I like it.

Which of these is most readable to you?

bool __must_check xchacha20poly1305_decrypt(
        u8 *dst, const u8 *src, const size_t src_len, const u8 *ad,
        const size_t ad_len, const u8 nonce[min_array_size(XCHACHA20POLY1305_NONCE_SIZE)],
        const u8 key[min_array_size(CHACHA20POLY1305_KEY_SIZE)]);

bool __must_check xchacha20poly1305_decrypt(
        u8 *dst, const u8 *src, const size_t src_len, const u8 *ad,
        const size_t ad_len, const u8 nonce[static XCHACHA20POLY1305_NONCE_SIZE],
        const u8 key[static CHACHA20POLY1305_KEY_SIZE]);

bool __must_check xchacha20poly1305_decrypt(
        u8 *dst, const u8 *src, const size_t src_len, const u8 *ad,
        const size_t ad_len, const u8 nonce[at_least XCHACHA20POLY1305_NONCE_SIZE],
        const u8 key[at_least CHACHA20POLY1305_KEY_SIZE]);

The macro function syntax of the first one means nested bracket brain
parsing. The second one means more `static` usage that might be
unfamiliar. The third one actually makes it kind of clear what's up.
It's got that weird-but-nice Objective-C-style sentence programming
thing.

Would somebody jump in here to tell me to stop sniffing glue? I feel
silly actually considering this, but here I am. Maybe this is actually
an okay idea?

Jason

Re: [PATCH libcrypto 1/2] array_size: introduce min_array_size() function decoration

[Ard Biesheuvel]

On Wed, 19 Nov 2025 at 20:04, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> On Wed, Nov 19, 2025 at 12:31:11AM +0100, Jason A. Donenfeld wrote:
> > There's also this other approach from 2001 that the C committee I guess
> > shot down: https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_205.htm
> > It is basically:
> >
> >     #define __at_least static
> >
> > We could attempt to do the same with `at_least`...
> >
> > It kind of feels like we're just inventing a language at that point
> > though.
>
> Actually, you know, the more this apparently terrible idea sits in my
> head, the more I like it.
>
> Which of these is most readable to you?
>
> bool __must_check xchacha20poly1305_decrypt(
>         u8 *dst, const u8 *src, const size_t src_len, const u8 *ad,
>         const size_t ad_len, const u8 nonce[min_array_size(XCHACHA20POLY1305_NONCE_SIZE)],
>         const u8 key[min_array_size(CHACHA20POLY1305_KEY_SIZE)]);
>
> bool __must_check xchacha20poly1305_decrypt(
>         u8 *dst, const u8 *src, const size_t src_len, const u8 *ad,
>         const size_t ad_len, const u8 nonce[static XCHACHA20POLY1305_NONCE_SIZE],
>         const u8 key[static CHACHA20POLY1305_KEY_SIZE]);
>
> bool __must_check xchacha20poly1305_decrypt(
>         u8 *dst, const u8 *src, const size_t src_len, const u8 *ad,
>         const size_t ad_len, const u8 nonce[at_least XCHACHA20POLY1305_NONCE_SIZE],
>         const u8 key[at_least CHACHA20POLY1305_KEY_SIZE]);
>
> The macro function syntax of the first one means nested bracket brain
> parsing. The second one means more `static` usage that might be
> unfamiliar. The third one actually makes it kind of clear what's up.
> It's got that weird-but-nice Objective-C-style sentence programming
> thing.
>
> Would somebody jump in here to tell me to stop sniffing glue? I feel
> silly actually considering this, but here I am. Maybe this is actually
> an okay idea?
>

I quite like it, actually.

Re: [PATCH libcrypto 1/2] array_size: introduce min_array_size() function decoration

[david laight]

On Wed, 19 Nov 2025 20:04:28 +0100
"Jason A. Donenfeld" <Jason@zx2c4.com> wrote:

> On Wed, Nov 19, 2025 at 12:31:11AM +0100, Jason A. Donenfeld wrote:
> > There's also this other approach from 2001 that the C committee I guess
> > shot down: https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_205.htm
> > It is basically:
> > 
> >     #define __at_least static
> > 
> > We could attempt to do the same with `at_least`...
> > 
> > It kind of feels like we're just inventing a language at that point
> > though.  
> 
> Actually, you know, the more this apparently terrible idea sits in my
> head, the more I like it.
> 
> Which of these is most readable to you?
> 
> bool __must_check xchacha20poly1305_decrypt(
>         u8 *dst, const u8 *src, const size_t src_len, const u8 *ad,
>         const size_t ad_len, const u8 nonce[min_array_size(XCHACHA20POLY1305_NONCE_SIZE)],
>         const u8 key[min_array_size(CHACHA20POLY1305_KEY_SIZE)]);
> 
> bool __must_check xchacha20poly1305_decrypt(
>         u8 *dst, const u8 *src, const size_t src_len, const u8 *ad,
>         const size_t ad_len, const u8 nonce[static XCHACHA20POLY1305_NONCE_SIZE],
>         const u8 key[static CHACHA20POLY1305_KEY_SIZE]);
> 
> bool __must_check xchacha20poly1305_decrypt(
>         u8 *dst, const u8 *src, const size_t src_len, const u8 *ad,
>         const size_t ad_len, const u8 nonce[at_least XCHACHA20POLY1305_NONCE_SIZE],
>         const u8 key[at_least CHACHA20POLY1305_KEY_SIZE]);

While bikeshedding...
I'd drop the pointless 'const' and always try to put a ptr/len pair on the same line.
So end up with:
bool __must_check xchacha20poly1305_decrypt(u8 *dst, const u8 *src, size_t src_len,
	const u8 *ad, size_t ad_len,
	const u8 nonce[at_least XCHACHA20POLY1305_NONCE_SIZE],
	const u8 key[at_least CHACHA20POLY1305_KEY_SIZE]);
or perhaps:
bool __must_check xchacha20poly1305_decrypt(u8 *dst,
	const u8 *src, size_t src_len, const u8 *ad, size_t ad_len,
	const u8 nonce[at_least XCHACHA20POLY1305_NONCE_SIZE],
	const u8 key[at_least CHACHA20POLY1305_KEY_SIZE]);
but I don't know what defines the length of '*ad'.

	David

> 
> The macro function syntax of the first one means nested bracket brain
> parsing. The second one means more `static` usage that might be
> unfamiliar. The third one actually makes it kind of clear what's up.
> It's got that weird-but-nice Objective-C-style sentence programming
> thing.
> 
> Would somebody jump in here to tell me to stop sniffing glue? I feel
> silly actually considering this, but here I am. Maybe this is actually
> an okay idea?
> 
> Jason
> 

Re: [PATCH libcrypto 1/2] array_size: introduce min_array_size() function decoration

[Herbert Xu]

Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> I wouldn't call that "asked for".
> 
> It was more a musing on how random that "static" syntax is and it's
> likely incomprehensible to a lot of people - but also pointing out
> that we already do have users of it, and saying that maybe it won't be
> incomprehensible once we have a lot of users.
> 
> So I'm definitely not pushing for it.
> 
> But I do suspect it makes people understand what the code does more...

Actually there is one reason for using a macro instead of static
directly, sparse still seems to choke on a non-static value for
static:

int foo(int n, int a[static n])
{
        return a[0]++;
}

This compiles correctly with gcc and clang, but sparse chokes on it:

a.c:1:29: error: undefined identifier 'n'
a.c:1:29: error: bad constant expression type

I was trying to use it in crypto/ecc.c where the arrays are
defined as ECC_MAX_DIGITS, but only the first ndigits are valid.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt