Re: unix_stream_connect and socket address resolution

[David Laight <david.laight.linux@gmail.com>]

On Sat, 18 Jul 2026 15:55:12 -0400
"John Ericson" <mail@johnericson.me> wrote:

> In [1] I observed what I considered some odd behavior in unix_stream_connect():
> 
> > 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/
>