linux-kernel - Re: [PATCH] crypto: chelsio: chtls: fix possible sleep-in-atomic-context bugs in abort_syn

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:   Fri, 27 Dec 2019 10:57:41 +0800
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Jia-Ju Bai <baijiaju1990@...il.com>
Cc:     atul.gupta@...lsio.com, davem@...emloft.net, tglx@...utronix.de,
        allison@...utok.net, arjun@...lsio.com,
        kstewart@...uxfoundation.org, edumazet@...gle.com,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] crypto: chelsio: chtls: fix possible
 sleep-in-atomic-context bugs in abort_syn_rcv()

On Wed, Dec 18, 2019 at 11:34:22AM +0800, Jia-Ju Bai wrote:
> The driver may sleep while holding a spinlock.
> The function call path (from bottom to top) in Linux 4.19 is:
> 
> drivers/crypto/chelsio/chtls/chtls_cm.c, 1806: 
> 	alloc_skb(GFP_KERNEL) in send_abort_rpl
> drivers/crypto/chelsio/chtls/chtls_cm.c, 1925: 
> 	send_abort_rpl in abort_syn_rcv
> drivers/crypto/chelsio/chtls/chtls_cm.c, 1920: 
> 	spin_lock in abort_syn_rcv
> 
> drivers/crypto/chelsio/chtls/chtls_cm.c, 1787: 
> 	alloc_skb(GFP_KERNEL) in send_defer_abort_rpl
> drivers/crypto/chelsio/chtls/chtls_cm.c, 1811: 
> 	send_defer_abort_rpl in send_abort_rpl
> drivers/crypto/chelsio/chtls/chtls_cm.c, 1925: 
>     send_abort_rpl in abort_syn_rcv
> drivers/crypto/chelsio/chtls/chtls_cm.c, 1920: 
>     spin_lock in abort_syn_rcv
> 
> alloc_skb(GFP_KERNEL) can sleep at runtime.
> 
> To fix these possible bugs, GFP_KERNEL is replaced with GFP_ATOMIC.
> Besides, in send_defer_abort_rpl(), error handling code is added to 
> handle the failure of alloc_skb().
> 
> These bugs are found by a static analysis tool STCheck written by myself.
> 
> Signed-off-by: Jia-Ju Bai <baijiaju1990@...il.com>
> ---
>  drivers/crypto/chelsio/chtls/chtls_cm.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/crypto/chelsio/chtls/chtls_cm.c b/drivers/crypto/chelsio/chtls/chtls_cm.c
> index aca75237bbcf..e6e4c3ddc368 100644
> --- a/drivers/crypto/chelsio/chtls/chtls_cm.c
> +++ b/drivers/crypto/chelsio/chtls/chtls_cm.c
> @@ -1805,8 +1805,11 @@ static void send_defer_abort_rpl(struct chtls_dev *cdev, struct sk_buff *skb)
>  	struct cpl_abort_req_rss *req = cplhdr(skb);
>  	struct sk_buff *reply_skb;
>  
> -	reply_skb = alloc_skb(sizeof(struct cpl_abort_rpl),
> -			      GFP_KERNEL | __GFP_NOFAIL);
> +	reply_skb = alloc_skb(sizeof(struct cpl_abort_rpl), GFP_ATOMIC);
> +	if (!reply_skb) {
> +		kfree_skb(skb);
> +		return;
> +	}

This code now makes no sense because it's just trying the same
kmalloc twice.  Perhaps it really needs to be deferred as its
name suggests?

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