netdev - 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: <e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co>
Date: Fri, 11 Apr 2025 16:44:43 +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: bytes_unsent forever elevated (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:
>>>> ...
>>>> 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.

Thanks,
Michal