All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Baron <jbaron@akamai.com>
To: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Cc: Dmitry Vyukov <dvyukov@google.com>,
	syzkaller <syzkaller@googlegroups.com>,
	Michal Kubecek <mkubecek@suse.cz>,
	Al Viro <viro@zeniv.linux.org.uk>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	Hannes Frederic Sowa <hannes@stressinduktion.org>,
	David Howells <dhowells@redhat.com>,
	Paul Moore <paul@paul-moore.com>,
	salyzyn@android.com, sds@tycho.nsa.gov, ying.xue@windriver.com,
	netdev <netdev@vger.kernel.org>,
	Kostya Serebryany <kcc@google.com>,
	Alexander Potapenko <glider@google.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Sasha Levin <sasha.levin@oracle.com>,
	Julien Tinnes <jln@google.com>, Kees Cook <keescook@google.com>,
	Mathias Krause <minipli@googlemail.com>
Subject: Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue (w/ Fixes:)
Date: Tue, 17 Nov 2015 11:13:43 -0500	[thread overview]
Message-ID: <564B5237.8080803@akamai.com> (raw)
In-Reply-To: <87ziydvasn.fsf_-_@doppelsaurus.mobileactivedefense.com>



On 11/16/2015 05:28 PM, Rainer Weikusat wrote:
> An AF_UNIX datagram socket being the client in an n:1 association with
> some server socket is only allowed to send messages to the server if the
> receive queue of this socket contains at most sk_max_ack_backlog
> datagrams. This implies that prospective writers might be forced to go
> to sleep despite none of the message presently enqueued on the server
> receive queue were sent by them. In order to ensure that these will be
> woken up once space becomes again available, the present unix_dgram_poll
> routine does a second sock_poll_wait call with the peer_wait wait queue
> of the server socket as queue argument (unix_dgram_recvmsg does a wake
> up on this queue after a datagram was received). This is inherently
> problematic because the server socket is only guaranteed to remain alive
> for as long as the client still holds a reference to it. In case the
> connection is dissolved via connect or by the dead peer detection logic
> in unix_dgram_sendmsg, the server socket may be freed despite "the
> polling mechanism" (in particular, epoll) still has a pointer to the
> corresponding peer_wait queue. There's no way to forcibly deregister a
> wait queue with epoll.
> 
> Based on an idea by Jason Baron, the patch below changes the code such
> that a wait_queue_t belonging to the client socket is enqueued on the
> peer_wait queue of the server whenever the peer receive queue full
> condition is detected by either a sendmsg or a poll. A wake up on the
> peer queue is then relayed to the ordinary wait queue of the client
> socket via wake function. The connection to the peer wait queue is again
> dissolved if either a wake up is about to be relayed or the client
> socket reconnects or a dead peer is detected or the client socket is
> itself closed. This enables removing the second sock_poll_wait from
> unix_dgram_poll, thus avoiding the use-after-free, while still ensuring
> that no blocked writer sleeps forever.
> 
> Signed-off-by: Rainer Weikusat <rweikusat@mobileactivedefense.com>
> Fixes: ec0d215f9420 ("af_unix: fix 'poll for write'/connected DGRAM sockets")
> ---
> 
> Additional remark about "5456f09aaf88/ af_unix: fix unix_dgram_poll()
> behavior for EPOLLOUT event": This shouldn't be an issue anymore with
> this change despite it restores the "only when writable" behaviour" as
> the wake up relay will also be set up once _dgram_sendmsg returned
> EAGAIN for a send attempt on a n:1 connected socket.
> 
> 

Hi,

My only comment was about potentially avoiding the double lock in the
write path, otherwise this looks ok to me.

Thanks,

-Jason

  reply	other threads:[~2015-11-17 16:13 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-12 11:07 Use-after-free in ep_remove_wait_queue Dmitry Vyukov
2015-10-12 12:02 ` Michal Kubecek
2015-10-12 12:14   ` Eric Dumazet
2015-10-12 12:17     ` Dmitry Vyukov
2015-11-06 13:06       ` Dmitry Vyukov
2015-11-06 14:58         ` Jason Baron
2015-11-06 15:15           ` Rainer Weikusat
2015-11-09 14:40             ` [PATCH] unix: avoid use-after-free " Rainer Weikusat
2015-11-09 18:25               ` David Miller
2015-11-10 17:16                 ` Rainer Weikusat
2015-11-09 22:44               ` Jason Baron
2015-11-10 17:38                 ` Rainer Weikusat
2015-11-22 21:43                   ` alternate queueing mechanism (was: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue) Rainer Weikusat
2015-11-10 21:55               ` [PATCH] unix: avoid use-after-free in ep_remove_wait_queue Rainer Weikusat
2015-11-11 12:28                 ` Hannes Frederic Sowa
2015-11-11 16:12                   ` Rainer Weikusat
2015-11-11 18:52                     ` Hannes Frederic Sowa
2015-11-13 19:06                       ` Rainer Weikusat
2015-11-11 17:35                 ` Jason Baron
2015-11-12 19:11                   ` Rainer Weikusat
2015-11-13 18:51                 ` Rainer Weikusat
2015-11-13 22:17                   ` Jason Baron
2015-11-15 18:32                     ` Rainer Weikusat
2015-11-17 16:08                       ` Jason Baron
2015-11-17 18:38                         ` Rainer Weikusat
2015-11-16 22:15                   ` Rainer Weikusat
2015-11-16 22:28                     ` [PATCH] unix: avoid use-after-free in ep_remove_wait_queue (w/ Fixes:) Rainer Weikusat
2015-11-17 16:13                       ` Jason Baron [this message]
2015-11-17 20:14                       ` David Miller
2015-11-17 21:37                         ` Rainer Weikusat
2015-11-17 22:09                           ` Rainer Weikusat
2015-11-19 23:48                             ` Rainer Weikusat
2015-11-17 22:48                           ` Rainer Weikusat
2015-11-18 18:15                         ` Rainer Weikusat
2015-11-18 23:39                           ` more statistics (was: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue (w/ Fixes:)) Rainer Weikusat
2015-11-19 23:52                       ` [PATCH] unix: avoid use-after-free in ep_remove_wait_queue (w/ Fixes:) Rainer Weikusat
2015-11-20 16:03                         ` Jason Baron
2015-11-20 16:21                           ` Rainer Weikusat
2015-11-20 22:07                         ` [PATCH] unix: avoid use-after-free in ep_remove_wait_queue Rainer Weikusat
2015-11-23 16:21                           ` Jason Baron
2015-11-23 17:30                           ` David Miller
2015-11-23 21:37                             ` Rainer Weikusat
2015-11-23 23:06                               ` Rainer Weikusat

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=564B5237.8080803@akamai.com \
    --to=jbaron@akamai.com \
    --cc=andreyknvl@google.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=hannes@stressinduktion.org \
    --cc=jln@google.com \
    --cc=kcc@google.com \
    --cc=keescook@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minipli@googlemail.com \
    --cc=mkubecek@suse.cz \
    --cc=netdev@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=rweikusat@mobileactivedefense.com \
    --cc=salyzyn@android.com \
    --cc=sasha.levin@oracle.com \
    --cc=sds@tycho.nsa.gov \
    --cc=syzkaller@googlegroups.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=ying.xue@windriver.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.