netdev - Re: [PATCH net] vsock/bpf: Handle EINTR connect() racing against sockmap update

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: <6850ad0c-68e5-4d8c-b80e-7c6adee80fdf@rbox.co>
Date: Fri, 23 Jan 2026 17:52:33 +0100
From: Michal Luczaj <mhal@...x.co>
To: John Fastabend <john.fastabend@...il.com>
Cc: Stefano Garzarella <sgarzare@...hat.com>,
 "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>, "Michael S. Tsirkin" <mst@...hat.com>,
 netdev@...r.kernel.org, bpf@...r.kernel.org, leonardi@...hat.com
Subject: Re: [PATCH net] vsock/bpf: Handle EINTR connect() racing against
 sockmap update

On 3/11/25 16:56, John Fastabend wrote:
> On 2025-03-07 17:01:11, Michal Luczaj wrote:
>> On 3/7/25 15:35, Stefano Garzarella wrote:
>>> On Fri, Mar 07, 2025 at 10:58:55AM +0100, Michal Luczaj wrote:
>>>>> Signal delivered during connect() may result in a disconnect of an already
>>>>> TCP_ESTABLISHED socket. Problem is that such established socket might have
>>>>> been placed in a sockmap before the connection was closed. We end up with a
>>>>> SS_UNCONNECTED vsock in a sockmap. And this, combined with the ability to
>>>>> reassign (unconnected) vsock's transport to NULL, breaks the sockmap
>>>>> contract. As manifested by WARN_ON_ONCE.
>>>>
>>>> Note that Luigi is currently working on a (vsock test suit) test[1] for a
>>>> related bug, which could be neatly adapted to test this bug as well.
>>>> [1]: https://lore.kernel.org/netdev/20250306-test_vsock-v1-0-0320b5accf92@redhat.com/
>>>
>>> Can you work with Luigi to include the changes in that series?
>>
>> I was just going to wait for Luigi to finish his work (no rush, really) and
>> then try to parametrize it.
>>
>> That is unless BPF/sockmap maintainers decide this thread's thing is a
>> sockmap thing and should be in tools/testing/selftests/bpf.
> 
> I think it makes sense to pull into selftests/bpf then it would get run
> from BPF CI so we can ensure BPF changes will keep this working
> correctly.

All right, a bit late (sorry), but here's an attempt:
https://lore.kernel.org/bpf/20260123-selftest-signal-on-connect-v1-0-b0256e7025b6@rbox.co/

> I guess the trick would be to see how long to run racer to get the
> warning but also not hang the CI. If you run it for 5 seconds or so
> does it trip? Or are you running this for minutes?
>
> If it takes too long to run it could be put into test_sockmap which
> has longer running things already. We also have some longer TCP
> compliance tests that would be good to start running in public somehow
> so might think a bit more how the infra for testing is going in
> sockmap side.

5 seconds is enough for the af_vsock case. I've added a af_unix test as
well, that one takes longer sometimes. But 5 seconds per protocol do add
up, the whole run takes some time.

[...]