netdev - Re: bytes_unsent forever elevated (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: <wxdauup4s54jjgi55n6m2eylnn2r64rorvsouevo3sivbpmnfb@yf5lt6yk7ro7>
Date: Tue, 15 Apr 2025 15:18:09 +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: bytes_unsent forever elevated (was Re: [PATCH net 2/2]
 vsock/test: Add test for SO_LINGER null ptr deref)

On Fri, Apr 11, 2025 at 04:44:43PM +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:
>>>>> ...
>>>>> Turns out there's a way to purge the loopback queue before worker processes
>>>>> it (I had no success with g2h). If you win that race, bytes_unsent stays
>>>>> elevated until kingdom come. Then you can close() the socket and watch as
>>>>> it lingers.
>>>>>
>>>>> connect(s)
>>>>>  lock_sock
>>>>>  while (sk_state != TCP_ESTABLISHED)
>>>>>    release_sock
>>>>>    schedule_timeout
>>>>>
>>>>> // virtio_transport_recv_connecting
>>>>> //   sk_state = TCP_ESTABLISHED
>>>>>
>>>>>                                       send(s, 'x')
>>>>>                                         lock_sock
>>>>>                                         virtio_transport_send_pkt_info
>>>>>                                           virtio_transport_get_credit
>>>>>                                    (!)      vvs->bytes_unsent += ret
>>>>>                                           vsock_loopback_send_pkt
>>>>>                                             virtio_vsock_skb_queue_tail
>>>>>                                         release_sock
>>>>>                                       kill()
>>>>>    lock_sock
>>>>>    if signal_pending
>>>>>      vsock_loopback_cancel_pkt
>>>>>        virtio_transport_purge_skbs (!)
>>>>>
>
>So is this something to worry about? The worst consequence I can think of
>is: linger with take place when it should not.

Yep, I see. My question is (I think I wrote this last week also), if the 
socket connected, even though we were interrupted, why do we close it?

Maybe we need to see what TCP does, but actually as you said, there may 
be a race with another thread that has already started using the socket 
after the successful connection.

So would it be better to avoid closing the socket if it is connected, 
even if it has been interrupted?

Thanks,
Stefano