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]
Date:   Thu, 27 Jan 2022 14:34:41 +0100
From:   Corentin Labbe <clabbe.montjoie@...il.com>
To:     Herbert Xu <herbert@...dor.apana.org.au>
Cc:     davem@...emloft.net, linux-arm-kernel@...ts.infradead.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: [PATCH] crypto: authenc - Fix sleep in atomic context in
 decrypt_tail

Le Wed, Jan 19, 2022 at 05:58:40PM +1100, Herbert Xu a écrit :
> On Tue, Jan 18, 2022 at 08:52:53AM +0100, Corentin Labbe wrote:
> >
> > With my patch, I got:
> > [   38.515668] BUG: sleeping function called from invalid context at crypto/skcipher.c:482
> > [   38.523708] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 84, name: 1c15000.crypto-
> > [   38.532176] preempt_count: 200, expected: 0
> > [   38.536381] CPU: 6 PID: 84 Comm: 1c15000.crypto- Not tainted 5.16.0-next-20220115-00124-g13473e8fac33-dirty #116
> > [   38.546551] Hardware name: Allwinner A83t board
> > [   38.551100]  unwind_backtrace from show_stack+0x10/0x14
> > [   38.556358]  show_stack from dump_stack_lvl+0x40/0x4c
> > [   38.561428]  dump_stack_lvl from __might_resched+0x118/0x154
> > [   38.567107]  __might_resched from skcipher_walk_virt+0xe8/0xec
> > [   38.572955]  skcipher_walk_virt from crypto_cbc_decrypt+0x2c/0x170
> > [   38.579147]  crypto_cbc_decrypt from crypto_skcipher_decrypt+0x38/0x5c
> > [   38.585680]  crypto_skcipher_decrypt from authenc_verify_ahash_done+0x18/0x34
> > [   38.592825]  authenc_verify_ahash_done from crypto_finalize_request+0x6c/0xe4
> > [   38.599974]  crypto_finalize_request from sun8i_ss_hash_run+0x73c/0xb98
> > [   38.606602]  sun8i_ss_hash_run from crypto_pump_work+0x1a8/0x330
> > [   38.612616]  crypto_pump_work from kthread_worker_fn+0xa8/0x1c4
> > [   38.618550]  kthread_worker_fn from kthread+0xf0/0x110
> > [   38.623701]  kthread from ret_from_fork+0x14/0x2c
> > [   38.628414] Exception stack(0xc2247fb0 to 0xc2247ff8)
> > [   38.633468] 7fa0:                                     00000000 00000000 00000000 00000000
> > [   38.641640] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > [   38.649809] 7fe0:i 00000000 00000000 00000000 00000000 00000013 00000000
> > 
> > This is when testing hmac(sha1) on my crypto driver sun8i-ss and crypto testing authenc(hmac-sha1-sun8i-ss,cbc(aes-generic)).
> > 
> > Do you have any idea to better fix my issue ?
> 
> This backtrace is caused by a bug in authenc:
> 
> ---8<---
> The function crypto_authenc_decrypt_tail discards its flags
> argument and always relies on the flags from the original request
> when starting its sub-request.
> 
> This is clearly wrong as it may cause the SLEEPABLE flag to be
> set when it shouldn't.
> 
> Fixes: 92d95ba91772 ("crypto: authenc - Convert to new AEAD interface")
> Reported-by: Corentin Labbe <clabbe.montjoie@...il.com>
> Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>
> 
> diff --git a/crypto/authenc.c b/crypto/authenc.c
> index 670bf1a01d00..17f674a7cdff 100644
> --- a/crypto/authenc.c
> +++ b/crypto/authenc.c
> @@ -253,7 +253,7 @@ static int crypto_authenc_decrypt_tail(struct aead_request *req,
>  		dst = scatterwalk_ffwd(areq_ctx->dst, req->dst, req->assoclen);
>  
>  	skcipher_request_set_tfm(skreq, ctx->enc);
> -	skcipher_request_set_callback(skreq, aead_request_flags(req),
> +	skcipher_request_set_callback(skreq, flags,
>  				      req->base.complete, req->base.data);
>  	skcipher_request_set_crypt(skreq, src, dst,
>  				   req->cryptlen - authsize, req->iv);
> -- 

This fixes my issue.

Tested-by: Corentin Labbe <clabbe.montjoie@...il.com>

Thanks

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ