Re: [PATCH] crypto: chelsio: chtls: fix possible sleep-in-atomic-context bugs in abort_syn_rcv()

From: Herbert Xu
Date: Thu Dec 26 2019 - 21:58:09 EST


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@xxxxxxxxx>
> ---
> 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@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt