[Bug 262172] UNIX Domain bind() - distinguish between random garbage and alive listening socket

From: <bugzilla-noreply_at_freebsd.org>
Date: Thu, 24 Feb 2022 16:46:05 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262172

            Bug ID: 262172
           Summary: UNIX Domain bind() - distinguish between random
                    garbage and alive listening socket
           Product: Base System
           Version: Unspecified
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: firk@cantconnect.ru

Created attachment 232076
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=232076&action=edit
patch for 12.3

The bind()/bindat() syscall for AF_UNIX returns EADDRINUSE when some file
already exist at the specified path. EADDRINUSE should mean "this address
already bound to someone", and this is not always true here. There may be just
some file (not a socket) or a dead socket (pending non-unlinked vnode from
already closed, previously bound socket). While the first case usually
considered as an application error, the second usually means "we need to remove
this stale entry and try again", but to do this we should first check if the
socket is really dead.

There is a hacky way to do this: try to connect to it, and see what happens,
but: 1) it is an extra unneeded system call,
2) is the socket is not dead, the listening application will receive spurious
connection request, which is not always desirable,
3) there is a problem to distinguish between ECONNREFUSED from a dead socket
and ECONNREFUSED from full-backlog; we can try to connect with a wrong protocol
(SOCK_STREAM vs SOCK_DGRAM etc) to get another errno, but anyway it is a hack

So I made a patch to return EEXIST instead or EADDRINUSE when there is not
really bound socket but just a random file or a dead socket. As this may cause
some incompatibilities, I added sysctl to optionally enable this feature.

-- 
You are receiving this mail because:
You are the assignee for the bug.