All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: Cong Wang <xiyou.wangcong@gmail.com>, netdev@vger.kernel.org
Cc: Cong Wang <cong.wang@bytedance.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	John Fastabend <john.fastabend@gmail.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Jakub Sitnicki <jakub@cloudflare.com>,
	Lorenz Bauer <lmb@cloudflare.com>
Subject: RE: [Patch bpf-next] unix_bpf: fix a potential deadlock in unix_dgram_bpf_recvmsg()
Date: Tue, 27 Jul 2021 09:12:17 -0700	[thread overview]
Message-ID: <610030612aaa3_199a412083d@john-XPS-13-9370.notmuch> (raw)
In-Reply-To: <20210723183630.5088-1-xiyou.wangcong@gmail.com>

Cong Wang wrote:
> From: Cong Wang <cong.wang@bytedance.com>
> 
> As Eric noticed, __unix_dgram_recvmsg() may acquire u->iolock
> too, so we have to release it before calling this function.
> 
> Fixes: 9825d866ce0d ("af_unix: Implement unix_dgram_bpf_recvmsg()")
> Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: John Fastabend <john.fastabend@gmail.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Jakub Sitnicki <jakub@cloudflare.com>
> Cc: Lorenz Bauer <lmb@cloudflare.com>
> Signed-off-by: Cong Wang <cong.wang@bytedance.com>
> ---
>  net/unix/unix_bpf.c | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/net/unix/unix_bpf.c b/net/unix/unix_bpf.c
> index db0cda29fb2f..b07cb30e87b1 100644
> --- a/net/unix/unix_bpf.c
> +++ b/net/unix/unix_bpf.c
> @@ -53,8 +53,9 @@ static int unix_dgram_bpf_recvmsg(struct sock *sk, struct msghdr *msg,
>  	mutex_lock(&u->iolock);
>  	if (!skb_queue_empty(&sk->sk_receive_queue) &&
>  	    sk_psock_queue_empty(psock)) {
> -		ret = __unix_dgram_recvmsg(sk, msg, len, flags);
> -		goto out;
> +		mutex_unlock(&u->iolock);
> +		sk_psock_put(sk, psock);
> +		return __unix_dgram_recvmsg(sk, msg, len, flags);
>  	}

Is there a reason to grab the mutex_lock(u->iolock) above the
skb_queue_emptyaand sk_psock_queue_empty checks?

Could it be move here just above the msg_bytes_ready label?

>  
>  msg_bytes_ready:
> @@ -68,13 +69,13 @@ static int unix_dgram_bpf_recvmsg(struct sock *sk, struct msghdr *msg,
>  		if (data) {
>  			if (!sk_psock_queue_empty(psock))
>  				goto msg_bytes_ready;
> -			ret = __unix_dgram_recvmsg(sk, msg, len, flags);
> -			goto out;
> +			mutex_unlock(&u->iolock);
> +			sk_psock_put(sk, psock);
> +			return __unix_dgram_recvmsg(sk, msg, len, flags);
>  		}
>  		copied = -EAGAIN;
>  	}
>  	ret = copied;
> -out:
>  	mutex_unlock(&u->iolock);
>  	sk_psock_put(sk, psock);
>  	return ret;
> -- 
> 2.27.0
> 

  reply	other threads:[~2021-07-27 16:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-23 18:36 [Patch bpf-next] unix_bpf: fix a potential deadlock in unix_dgram_bpf_recvmsg() Cong Wang
2021-07-27 16:12 ` John Fastabend [this message]
2021-07-28  3:06   ` Cong Wang
2021-07-28 10:12 ` Jakub Sitnicki
2021-07-28 18:52   ` John Fastabend
2021-07-30 19:45     ` Andrii Nakryiko

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=610030612aaa3_199a412083d@john-XPS-13-9370.notmuch \
    --to=john.fastabend@gmail.com \
    --cc=cong.wang@bytedance.com \
    --cc=daniel@iogearbox.net \
    --cc=eric.dumazet@gmail.com \
    --cc=jakub@cloudflare.com \
    --cc=lmb@cloudflare.com \
    --cc=netdev@vger.kernel.org \
    --cc=xiyou.wangcong@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.