netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: "Iwashima, Kuniyuki" <kuniyu@amazon.co.jp>, Kirill Tkhai <tkhai@ya.ru>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
	"edumazet@google.com" <edumazet@google.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH net v2] unix: Fix race in SOCK_SEQPACKET's unix_dgram_sendmsg()
Date: Mon, 05 Dec 2022 10:22:15 +0100	[thread overview]
Message-ID: <216de1827267077a19c5ed3e540b7db74afd1fc0.camel@redhat.com> (raw)
In-Reply-To: <53BD8023-E114-4B3E-BB07-C1889C8A3E95@amazon.co.jp>

On Fri, 2022-12-02 at 23:18 +0000, Iwashima, Kuniyuki wrote:
> 
> > On Dec 3, 2022, at 7:44, Kirill Tkhai <tkhai@ya.ru> wrote:
> > > On 01.12.2022 12:30, Paolo Abeni wrote:
> > > > On Sun, 2022-11-27 at 01:46 +0300, Kirill Tkhai wrote:
> > > > There is a race resulting in alive SOCK_SEQPACKET socket
> > > > may change its state from TCP_ESTABLISHED to TCP_CLOSE:
> > > > 
> > > > unix_release_sock(peer)                  unix_dgram_sendmsg(sk)
> > > >  sock_orphan(peer)
> > > >    sock_set_flag(peer, SOCK_DEAD)
> > > >                                           sock_alloc_send_pskb()
> > > >                                             if !(sk->sk_shutdown & SEND_SHUTDOWN)
> > > >                                               OK
> > > >                                           if sock_flag(peer, SOCK_DEAD)
> > > >                                             sk->sk_state = TCP_CLOSE
> > > >  sk->sk_shutdown = SHUTDOWN_MASK
> > > > 
> > > > 
> > > > After that socket sk remains almost normal: it is able to connect, listen, accept
> > > > and recvmsg, while it can't sendmsg.
> > > > 
> > > > Since this is the only possibility for alive SOCK_SEQPACKET to change
> > > > the state in such way, we should better fix this strange and potentially
> > > > danger corner case.
> > > > 
> > > > Also, move TCP_CLOSE assignment for SOCK_DGRAM sockets under state lock
> > > > to fix race with unix_dgram_connect():
> > > > 
> > > > unix_dgram_connect(other)            unix_dgram_sendmsg(sk)
> > > >                                       unix_peer(sk) = NULL
> > > >                                       unix_state_unlock(sk)
> > > >  unix_state_double_lock(sk, other)
> > > >  sk->sk_state  = TCP_ESTABLISHED
> > > >  unix_peer(sk) = other
> > > >  unix_state_double_unlock(sk, other)
> > > >                                       sk->sk_state  = TCP_CLOSED
> > > > 
> > > > This patch fixes both of these races.
> > > > 
> > > > Fixes: 83301b5367a9 ("af_unix: Set TCP_ESTABLISHED for datagram sockets too")
> > > 
> > > I don't think this commmit introduces the issues, both behavior
> > > described above appear to be present even before?
> > 
> > 1)Hm, I pointed to the commit suggested by Kuniyuki without checking it.
> > 
> > Possible, the real problem commit is dc56ad7028c5 "af_unix: fix potential NULL deref in unix_dgram_connect()",
> > since it added TCP_CLOSED assignment to unix_dgram_sendmsg().
> 
> The commit just moved the assignment.
> 
> Note unix_dgram_disconnected() is called for SOCK_SEQPACKET 
> after releasing the lock, and 83301b5367a9 introduced the 
> TCP_CLOSE assignment.

I'm sorry for the back and forth, I think I initally misread the code.
I agree 83301b5367a9 is good fixes tag.

> > 2)What do you think about initial version of fix?
> > 
> > https://patchwork.kernel.org/project/netdevbpf/patch/38a920a7-cfba-7929-886d-c3c6effc0c43@ya.ru/
> > 
> > Despite there are some arguments, I'm not still sure that v2 is better.

v1 introduces quite a few behavior changes (different error code,
different cleanup schema) that could be IMHO more risky for a stable
patch. I suggest to pick the minimal change that addresses the issue
(v2 in this case).

Thanks,

Paolo


  reply	other threads:[~2022-12-05  9:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-26 22:46 [PATCH net v2] unix: Fix race in SOCK_SEQPACKET's unix_dgram_sendmsg() Kirill Tkhai
2022-11-26 23:35 ` Kuniyuki Iwashima
2022-12-01  9:30 ` Paolo Abeni
2022-12-02 22:43   ` Kirill Tkhai
2022-12-02 23:18     ` Iwashima, Kuniyuki
2022-12-05  9:22       ` Paolo Abeni [this message]
2022-12-05 17:07         ` Kirill Tkhai
2022-12-03 10:37     ` Kirill Tkhai

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=216de1827267077a19c5ed3e540b7db74afd1fc0.camel@redhat.com \
    --to=pabeni@redhat.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=kuniyu@amazon.co.jp \
    --cc=netdev@vger.kernel.org \
    --cc=tkhai@ya.ru \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).