netdev - Re: why would EPIPE cause socket port to change?

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: <Pine.LNX.4.64.0701231140320.21464@twinlark.arctic.org>
Date:	Tue, 23 Jan 2007 12:11:01 -0800 (PST)
From:	dean gaudet <dean@...tic.org>
To:	Rick Jones <rick.jones2@...com>
cc:	Herbert Xu <herbert@...dor.apana.org.au>, netdev@...r.kernel.org
Subject: Re: why would EPIPE cause socket port to change?

On Tue, 23 Jan 2007, Rick Jones wrote:

> Herbert Xu wrote:
> > Prior to the last write, the socket entered the CLOSED state meaning
> > that the old port is no longer allocated to it.  As a result, the
> > last write operates on an unconnected socket which causes a new local
> > port to be allocated as an autobind.  It then fails because the socket
> > is still not connected.
> > 
> > So any attempt to run getsockname after an error on the socket is
> > simply buggy.
> 
> But falls within the principle of least surprise doesn't it?  Unless the
> application has called close() or bind(), it does seem like a reasonable
> expectation that the port assignments are not changed.

i sampled a few other OSes...

netbsd returns EINVAL after close
freebsd returns ECONNRESET after close
OSX retains the same port number
solaris 10 returns port 0

actually any of those behaviours seems more appropriate than randomly 
assigning a new port :)  but i like the ENOTCONN suggestion from Michael 
Tokarev the best... it matches the ENOTCONN from getpeername.

> > (fwiw this is one of two reasons i've found for libnss-ldap to leak
> > sockets... causing nscd to crash.)
> 
> Of course, that seems rather odd too - why does libnss-ldap check the socket
> name on a socket after an EPIPE anyway?

libnss-ldap has some code which attempts to determine if its private 
socket has been trampled on in between calls to the library... and to do 
this it caches getsockname/getpeername results and compares them every 
time the library is re-entered... and when there's a mismatch it leaks a 
socket (eventually crashing nscd if you're using that).  i've been trying 
to band-aid over the problem:

http://bugzilla.padl.com/show_bug.cgi?id=304
http://bugzilla.padl.com/show_bug.cgi?id=305

but i'm probably going to need to approach it from another direction -- 
make libnss-ldap monitor the ldap library results so it knows when there's 
been a read/write error so that it stops doing this 
getsockname/getpeername thing after the error has occured.

-dean
-
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