netdev - Re: connect(2) reassociation regression

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: <20130316203955.GA23495@wilbur.25thandClement.com>
Date:	Sat, 16 Mar 2013 13:39:55 -0700
From:	William Ahern <william@...handclement.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: connect(2) reassociation regression

On Sat, Mar 16, 2013 at 07:51:07AM -0700, Eric Dumazet wrote:
> On Fri, 2013-03-15 at 22:56 -0700, William Ahern wrote:
> > I've stumbled upon what may be a regression in connect(2) behavior.
<snip>
> > At some point in the 3.x cycle (maybe after 3.2.0) something was changed.
> > Whereas previously any reassociation worked, regardless of destination
> > network, now if the _first_ association is to the loopback, any subsequent
> > association to non-loopback fails with EINVAL. However, if the loopback is
> > the second or later association then everything continues to work. In other
> > words, the sequence
> > 
<snip>
> 
> There is an issue as the connect() call sets both local address:port and
> remote address, in the case the local address was not already set by a
> prior bind().
> 
> And once bound to a local address, its not really clear if we are
> allowed to bind to a different one, and fall in the possible traps of
> SO_REUSEADDR and find another socket bound to the same local addr:port.
> 
> So if the second connect() also change the source port, I am pretty sure
> some applications will badly break.
> 
> I would just avoid the problem of handling this mess, and let the
> application close the socket and allocate a new one.

This is for UDP, not TCP. The alternative is sendto/recvfrom. For a
non-blocking, recursive DNS library reopening sockets all of the time is
really messy.

> Changing the kernel behavior on these kind of unspecified stuff might
> break some other applications.

Indeed. The behavior _was_ changed, and my application broke, and
potentially many other applications.

> Clearly the BSD API was bad, as the connect() is a 'super operation',
> not only setting the remote address:port, but also the local
> address:port given the current routing table.

Well, AFAICT Linux implemented this behavior for years. FWIW, Solaris also
implements this behavior. It's been universal until recently.

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