netdev - Re: [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]

Message-ID: <20151030210943.GJ22011@ZenIV.linux.org.uk>
Date:	Fri, 30 Oct 2015 21:09:43 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	David Laight <David.Laight@...LAB.COM>
Cc:	'David Holland' <dholland-tech@...bsd.org>,
	Alan Burlison <Alan.Burlison@...cle.com>,
	"Casper.Dik@...cle.com" <Casper.Dik@...cle.com>,
	David Miller <davem@...emloft.net>,
	"eric.dumazet@...il.com" <eric.dumazet@...il.com>,
	"stephen@...workplumber.org" <stephen@...workplumber.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect
 for sockets in accept(3)

On Fri, Oct 30, 2015 at 05:43:21PM +0000, David Laight wrote:

> ISTM that the correct call should be listen(fd, 0);
> Although that doesn't help a thread stuck in recvmsg() for a datagram.
> 
> It is also tempting to think that close(fd) should sleep until all
> io activities using that fd have completed - whether or not blocking
> calls are woken.

Sigh...  The kernel has no idea when other threads are done with "all
io activities using that fd" - it can wait for them to leave the
kernel mode, but there's fuck-all it can do about e.g. a userland
loop doing write() until there's more data to send.  And no, you can't
rely upon them catching EBADF on the next iteration - by the time they
get there, close() might very well have returned and open() from yet
another thread might've grabbed the same descriptor.  Welcome to your
data being written to hell knows what...

That's precisely the reason why "wait in close()" kind of semantics
is worthless - the races are still there, and having them a bit
harder to hit just makes them harder to debug.  Worse, it might
create an impression of safety where there's none to be had.
--
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