Re: defying original 4.3BSD sockets constraint

On Sat, Apr 18, 2026 at 10:27:28AM -0700, Gleb Smirnoff wrote:
T> On Sat, Apr 18, 2026 at 08:35:58AM +0200, Michael Tuexen wrote:
T> M> > https://reviews.freebsd.org/D56489
T> M> > 
T> M> > I've been thinking of this for almost a week already and I don't see any cons.
T> M> > Pros are listed in the review - clean way to improve parallelism of connect(2).
T> M> > Maybe I am missing something?  Decided to post for a wider audience than just
T> M> > the reviews.f.o.  Please speak up if you think I am missing something!
T> M> I think the sequence of bind() operations is not important.
T> M> 
T> M> If I understand you correctly, you say bind(specific) after bind(wildcard)
T> M> is bad, since the instance of bind(specific) is stealing packets.
T> M> 
T> M> The same applies (in my view) for bind(wildcard) after bind(specific).
T> M> If bind(wildcard) succeeds, the caller assumes that it gets all packets,
T> M> but that is not true.
T> M> 
T> M> The only difference is when the "stealer" took action.
T> 
T> I see your point.  With current code the victim would get EADDRINUSE and thus
T> will learn that a stealer exists.  With my change that would not happen.  Of
T> course 99% of software set SO_REUSEADDR and thus bypass this check.

Couple important corrections.  In your above quote you are talking about both
victim and stealer using bind(2).  With my patch this behavior doesn't change
(need to push newer version to reviews.f.o.).  What changes is presence of a
fully connected socket affecting bind(2).

The only scenario that changes is the following:

1) Stealer uses UDP socket.  TCP bypasses the check since 4658dc8325e03.
2) Stealer does bind(2) and connect(2) to a remote peer.  It needs to know
   what port the victim is going to use in the future and what peer it is
   going to steal from.
3) Victim creates socket and does bind(2).  Before it would get EADDRINUSE,
   now it would succeed and stealer would be able to steal traffic from peer.

It is hard to me to make a security judgement here.  Now a local unpriveleged
user is able to disrupt function of a local daemon that uses unpriveleged UDP
port when the daemon is restarted.  With my change it won't be able to disrupt
its restart, but would be able steal some of its traffic after restart.  An
imaginable scenario is a Counter Strike server with malicious local users.

-- 
Gleb Smirnoff