netdev - Bug report: epoll can fail to report EPOLLOUT when unix datagram socket peer is closed

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-next>] [day] [month] [year] [list]

Message-ID: <CAOyqgcXzie6xRSEfVvtSS=uSkEaBxP-LjCcUxXLoqCjbvTO4yg@mail.gmail.com>
Date:   Tue, 26 Jun 2018 07:18:22 -0700
From:   Ian Lance Taylor <iant@...ang.org>
To:     netdev@...r.kernel.org
Subject: Bug report: epoll can fail to report EPOLLOUT when unix datagram
 socket peer is closed

I'm reporting what appears to be a bug in the Linux kernel's epoll
support.  It seems that epoll appears to sometimes fail to report an
EPOLLOUT event when the other side of an AF_UNIX/SOCK_DGRAM socket is
closed.  This bug report started as a Go program reported at
https://golang.org/issue/23604.  I've written a C program that
demonstrates the same symptoms, at
https://github.com/golang/go/issues/23604#issuecomment-398945027 .

The C program sets up an AF_UNIX/SOCK_DGRAM server and serveral
identical clients, all running in non-blocking mode.  All the
non-blocking sockets are added to epoll, using EPOLLET.  The server
periodically closes and reopens its socket.  The clients look for
ECONNREFUSED errors on their write calls, and close and reopen their
sockets when they see one.

The clients will sometimes fill up their buffer and block with EAGAIN.
At that point they expect the poller to return an EPOLLOUT event to
tell them when they are ready to write again.  The expectation is that
either the server will read data, freeing up buffer space, or will
close the socket, which should cause the sending packets to be
discarded, freeing up buffer space.  Generally the EPOLLOUT event
happens.  But sometimes, the poller never returns such an event, and
the client stalls.  In the test program this is reported as a client
that waits more than 20 seconds to be told to continue.

A similar bug report was made, with few details, at
https://stackoverflow.com/questions/38441059/edge-triggered-epoll-for-unix-domain-socket
.

I've tested the program and seen the failure on kernel 4.9.0-6-amd64.
A colleague has tested the program and seen the failure on
4.18.0-smp-DEV #3 SMP @1529531011 x86_64 GNU/Linux.

If there is a better way for me to report this, please let me know.

Thanks for your attention.

Ian