Re: unix_stream_connect and socket address resolution

On Sat, 18 Jul 2026 15:55:12 -0400
"John Ericson" [off-list ref] wrote:

In [1] I observed what I considered some odd behavior in unix_stream_connect():

quoted

I was hoping this was going to be a simple matter of factoring out the
back half of `unix_stream_connect`. No such luck was had, because
actually instead of `unix_stream_connect` looking up the socket from the
VFS once, it does it repeatedly in the same loop that is used to deal
with full listening queues.

(This behavior is rather surprising to me, because it would allow a
deleted and recreated socket to be picked up on the next loop iteration.
But, I don't want to make any UAPI-visible changes in this patch series,
so I did not consider changing it.)  

I had said I didn't want to consider changing this yet in my patch
series, but based on the feedback I received for a second version of
that patch series, I now actually think it is a good idea after all to
discuss this first, and see if it should be changed prior to my patch
series. (This discussion will inform what the code looks like before I
do my v2 patch series, and how big or small that patch series is.)

Here are two scenarios where the current behavior of
`unix_stream_connect` is surprising:

File system version:

1. server binds socket `/foo/bar`

2. clients fill up the accept queue, begin looping

3. `mv /foo /foo2; mkdir /foo`

4. another server binds `/foo/bar`

5. clients connect to the second server instead

The loop in question is within `unix_stream_connect` itself, not in
user code. I consider it very surprising that `/foo/bar` is looked up
multiple times during a single system call.

Abstract socket version:

1. server binds abstract socket `@foo`

2. clients fill up the accept queue, begin looping

3. server closes its socket (or exits), releasing the abstract name

4. another server binds `@foo`

5. clients connect to the second server instead

For abstract sockets we cannot play tricks with `mv`: the first server
does need to relinquish `@foo` itself. But still, the result is the same
where a different socket is resolved on the next loop iteration in
`unix_stream_connect`. I am not sure it is fair to call this a TOCTOU
issue exactly, but it feels very similar to one.

The more natural semantics in my view would be to first resolve the
address to a socket, and then loop holding that resolved socket
constant. With these semantics:

- In the `mv` case, the retrying clients continue to try connecting to
  the original socket, now at `/foo2/bar`.

- In the close case, the retrying clients fail, and do not connect to
  any new socket at the same path or abstract name.

What do you all think? Is this better? If so, is this a security fix
which can be made unconditionally, or, absent a real concrete attack
vector, is this a UAPI-breaking change which is automatically out of
scope, and would thus need an explicit opt-in mechanism?

Looking forward to feedback,

My $0.02

If you assume that the client isn't responsible for restarting the server,
then there is no strong timing relation between creating a new server
(by any means) and the connect request from the client.
In other words both the above are very similar to the client being
preempted at the start of the connect() system call.

What you need to do is hard link foo to foo1, create the new
socket at foo2/bar then mv foo2 to foo so that it is atomic.
But I suspect hard links to directories aren't allowed any more :-(
(Creating 'random' hard links to directories used to be 'fun',
you could get 'find' in a right mess.)

	David

John

[1]: https://lore.kernel.org/all/20260703073948.2541875-3-John.Ericson@Obsidian.Systems/ (local)