unix: Fix a socket leakHEADmain

When connecting a unix domain stream socket, we
1. look up the peer (listening) socket,
2. allocate a new socket
3. add the new socket to the listening socket's queue

Prior to commit 26147c51546e, this sequence of operations was
synchronized by a pool mutex, also acquired in uipc_close().

After commit 26147c51546e, we drop the vnode pool lock immediately after
finding the peer socket via a filesystem lookup.  This creates a window
where it's possible for a connection to add a new socket to the
listening queue after the listening queue has been aborted.

Fix the race by restoring the old behaviour of holding the pool lock
across the solisten_enqueue() call.  This is a bit ugly since we need to
pass a mutex lock and a vnode through a couple of layers, but it seems
like a low-risk solution.  Alternately we could add some flag to the
listening socket which indicates that no new connections are to be
accepted, but I think this will require some changes to the generic
socket code.

Reported by:	pho
Fixes:		26147c51546e ("unix: pin the pathname peer by reference across the connect")
Reviewed by:	olce, kib, John Ericson <John.Ericson@Obsidian.Systems>
Differential Revision:	https://reviews.freebsd.org/D59201

0 files changed, 0 insertions, 0 deletions