public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: kernel test robot <lkp@intel.com>,
	llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: crypto/hmac.c:251:12: warning: stack frame size (1152) exceeds limit (1024) in 'hmac_setkey_ahash'
Date: Sat, 18 Apr 2026 10:32:19 +0100	[thread overview]
Message-ID: <20260418103219.1024d2ce@pumpkin> (raw)
In-Reply-To: <aeGwENQpQIlY1-d8@gondor.apana.org.au>

On Fri, 17 Apr 2026 11:59:12 +0800
Herbert Xu <herbert@gondor.apana.org.au> wrote:

> On Thu, Apr 16, 2026 at 11:24:06AM +0100, David Laight wrote:
> >  
> > >    250	  
> > >  > 251	static int hmac_setkey_ahash(struct crypto_ahash *parent,    
> > >    252				     const u8 *inkey, unsigned int keylen)
> > >    253	{
> > >    254		struct ahash_hmac_ctx *tctx = crypto_ahash_ctx(parent);
> > >    255		struct crypto_ahash *fb = crypto_ahash_fb(tctx->hash);
> > >    256		int ds = crypto_ahash_digestsize(parent);
> > >    257		int bs = crypto_ahash_blocksize(parent);
> > >    258		int ss = crypto_ahash_statesize(parent);
> > >    259		HASH_REQUEST_ON_STACK(req, fb);
> > >    260		u8 *opad = &tctx->pads[ss];  
> > 
> > Is ss actually guaranteed to be not smaller than bs ?  
> 
> Yes, it's checked in hmac_create_ahash:
> 
>         ds = halg->digestsize;
>         ss = halg->statesize;
>         if (ds > alg->cra_blocksize || ss < alg->cra_blocksize)
>                 goto err_free_inst;
> 
> Thanks,

Ok, so the comment on the definition of 'struct crypto_ahash' could
reasonably be changed to say that pads[] is large enough for two copies
of any the digest, block or state.
And then line 260 (above) changed to use 'bs'.
The memcpy(opad, ipad, bs) could also be replaced by putting
	opad[i] = ipad[i] ^ HMAC_OPAD_VALUE;
into the loop.

None of this helps find why this build explodes the stack.
I've had another look and can't see any inline functions calls
that might cause grief.

	David


  reply	other threads:[~2026-04-18  9:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-16  3:04 crypto/hmac.c:251:12: warning: stack frame size (1152) exceeds limit (1024) in 'hmac_setkey_ahash' kernel test robot
2026-04-16 10:24 ` David Laight
2026-04-17  3:59   ` Herbert Xu
2026-04-18  9:32     ` David Laight [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-01-12 22:49 kernel test robot
2025-12-03  0:12 kernel test robot
2025-10-28 15:04 kernel test robot
2025-09-14 21:06 kernel test robot
2025-07-23 21:28 kernel test robot
2025-06-19 12:13 kernel test robot

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=20260418103219.1024d2ce@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=llvm@lists.linux.dev \
    --cc=oe-kbuild-all@lists.linux.dev \
    /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