All of lore.kernel.org
 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 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.