netdev - Re: Fw: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

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

Date:	Tue, 20 Oct 2015 19:31:25 +0100
From:	Alan Burlison <Alan.Burlison@...cle.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	Stephen Hemminger <stephen@...workplumber.org>,
	netdev@...r.kernel.org
Subject: Re: Fw: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect
 for sockets in accept(3)

On 20/10/2015 16:30, Eric Dumazet wrote:

> A close() does _not_ wakeup an accept() or a poll() (this is exactly the
> same problem), or any blocking system call using the same 'file'

Not waking up the accept() is one thing, allowing the accept() to 
successfully complete some indeterminate time after the socket has been 
closed is something else entirely. You shouldn't have to call shutdown() 
to terminate an accept() on a socket, close() should suffice. Yes, if 
you want to use the shutdown() 'feature' to kick the accept() thread out 
of the call to accept() without closing the FD and you don't care about 
cross-platform compatibility then you can call shutdown() followed by 
close(). However that's only ever required on Linux as far as I can 
tell, and even on Linux applications that deal with the thread race by 
other means shouldn't be forced to use shutdown() when just close() 
would suffice.

The problem with poll() is that it returns immediately when passed a FD 
that is in the listening state. rather than waiting until there's an 
incoming connection to handle. As I said, that means you can't use 
poll() to multiplex between read/write/accept sockets.

> close() man page states :
>
> NOTES
>        It  is  probably unwise to close file descriptors while they may be in
>        use by system calls in other threads in the  same  process.   Since  a
>        file  descriptor may be reused, there are some obscure race conditions
>        that may cause unintended side effects.
>
> You are in this grey zone.

No, the race issue with file descriptor reuse and the close() behaviour 
are not the same thing. The manpage comment is correct, but not relevant.

-- 
Alan Burlison
--
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html