Re: crypto/hmac.c:251:12: warning: stack frame size (1152) exceeds limit (1024) in 'hmac_setkey_ahash'

[David Laight]

On Fri, 17 Apr 2026 11:59:12 +0800
Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> 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