netdev - connect() disconnects TCP_ESTABLISHED (was Re: [PATCH net 2/2] vsock/test: Add test for SO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <54481a3b-280f-4945-a513-f8a93b5568b4@rbox.co>
Date: Fri, 11 Apr 2025 16:46:09 +0200
From: Michal Luczaj <mhal@...x.co>
To: Stefano Garzarella <sgarzare@...hat.com>
Cc: "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
 netdev@...r.kernel.org
Subject: connect() disconnects TCP_ESTABLISHED (was Re: [PATCH net 2/2]
 vsock/test: Add test for SO_LINGER null ptr deref)

On 4/11/25 15:21, Stefano Garzarella wrote:
> On Fri, Apr 04, 2025 at 12:06:36AM +0200, Michal Luczaj wrote:
>> On 4/1/25 12:32, Stefano Garzarella wrote:
>>> On Tue, Mar 25, 2025 at 02:22:45PM +0100, Michal Luczaj wrote:
>>>> ...
>>>> That said, I may be missing a bigger picture, but is it worth supporting
>>>> this "signal disconnects TCP_ESTABLISHED" behaviour in the first place?
>>>
>>> Can you elaborate a bit?
>>
>> There isn't much to it. I just wondered if connect() -- that has already
>> established a connection -- could ignore the signal (or pretend it came too
>> late), to avoid carrying out this kind of disconnect.
> 
> Okay, I see now!
> 
> Yeah, I think after `schedule_timeout()`, if `sk->sk_state == 
> TCP_ESTABLISHED` we should just exit from the while() and return a
> succesful connection IMHO, as I fixed for closing socket.
>
> Maybe we should check what we do in other cases such as AF_UNIX,
> AF_INET.

OK, I suspect that would simplify things a lot (and solve the other issues
mentioned; the EINTR connect() issue and the elevated bytes_unsent issue).

Please feel free to tackle it, or let me do this once I'm done with the
backlog.

Thanks,
Michal