netdev - Re: [PATCH v2 net-next] af_unix: ensure POLLOUT on remote close() for connected dgram socket

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20180803.164444.8668116949268659.davem@davemloft.net>
Date:   Fri, 03 Aug 2018 16:44:44 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     jbaron@...mai.com
Cc:     netdev@...r.kernel.org, rientjes@...gle.com,
        rweikusat@...ileactivedefense.com, edumazet@...gle.com
Subject: Re: [PATCH v2 net-next] af_unix: ensure POLLOUT on remote close()
 for connected dgram socket

From: Jason Baron <jbaron@...mai.com>
Date: Fri,  3 Aug 2018 17:24:53 -0400

> Applications use -ECONNREFUSED as returned from write() in order to
> determine that a socket should be closed. However, when using connected
> dgram unix sockets in a poll/write loop, a final POLLOUT event can be
> missed when the remote end closes. Thus, the poll is stuck forever:
> 
>           thread 1 (client)                   thread 2 (server)
> 
> connect() to server
> write() returns -EAGAIN
> unix_dgram_poll()
>  -> unix_recvq_full() is true
>                                        close()
>                                         ->unix_release_sock()
>                                          ->wake_up_interruptible_all()
> unix_dgram_poll() (due to the
>      wake_up_interruptible_all)
>  -> unix_recvq_full() still is true
>                                          ->free all skbs
> 
> 
> Now thread 1 is stuck and will not receive anymore wakeups. In this
> case, when thread 1 gets the -EAGAIN, it has not queued any skbs
> otherwise the 'free all skbs' step would in fact cause a wakeup and
> a POLLOUT return. So the race here is probably fairly rare because
> it means there are no skbs that thread 1 queued and that thread 1
> schedules before the 'free all skbs' step.
> 
> This issue was reported as a hang when /dev/log is closed.
> 
> The fix is to signal POLLOUT if the socket is marked as SOCK_DEAD, which
> means a subsequent write() will get -ECONNREFUSED.
> 
> Reported-by: Ian Lance Taylor <iant@...ang.org>
> Cc: David Rientjes <rientjes@...gle.com>
> Cc: Rainer Weikusat <rweikusat@...ileactivedefense.com>
> Cc: Eric Dumazet <edumazet@...gle.com>
> Signed-off-by: Jason Baron <jbaron@...mai.com>
> ---
> v2: use check for SOCK_DEAD, since skb's can be purged in unix_sock_destructor()

Applied, thanks Jason.