netdev - Re: 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] [day] [month] [year] [list]

Message-ID: <f56zmuz36at6d5q43l7uk5ww6povxvlvzxyadpu4yqr7ju4soh@iaravg33efpg>
Date: Tue, 15 Apr 2025 15:33:45 +0200
From: Stefano Garzarella <sgarzare@...hat.com>
To: Michal Luczaj <mhal@...x.co>
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: Re: connect() disconnects TCP_ESTABLISHED (was Re: [PATCH net 2/2]
 vsock/test: Add test for SO_LINGER null ptr deref)

On Fri, Apr 11, 2025 at 04:46:09PM +0200, Michal Luczaj wrote:
>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).

Yeah, I just replied to the other thread with the same consideration!

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

-ENOTIME for this week here, so if you want, go head ;-)

I'd like to follow what TCP does in that case (connect() interrupted but 
socket is connected).

Thanks,
Stefano