BPF List
 help / color / mirror / Atom feed
From: Michal Luczaj <mhal@rbox.co>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: netdev@vger.kernel.org, "Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
	bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Luigi Leonardi" <leonardi@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Wongi Lee" <qwerty@theori.io>,
	"Eugenio Pérez" <eperezma@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Eric Dumazet" <edumazet@google.com>,
	kvm@vger.kernel.org, "Paolo Abeni" <pabeni@redhat.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Simon Horman" <horms@kernel.org>,
	"Hyunwoo Kim" <v4bel@theori.io>,
	"Jakub Kicinski" <kuba@kernel.org>,
	virtualization@lists.linux.dev, stable@vger.kernel.org
Subject: Re: [PATCH net v2 1/5] vsock/virtio: discard packets if the transport changes
Date: Fri, 17 Jan 2025 23:02:58 +0100	[thread overview]
Message-ID: <e3085fe8-3dae-40b2-970f-b8cda956a8f5@rbox.co> (raw)
In-Reply-To: <pl4mhcim7v3ukv6eseynh6x2r6nftf7yuayjzd3ftyupwy5r2h@ixmlevubqzb2>

On 1/16/25 09:57, Stefano Garzarella wrote:
> On Tue, Jan 14, 2025 at 05:31:08PM +0100, Michal Luczaj wrote:
>>> ...
>>> Maybe we need to look better at the release, and prevent it from
>>> removing the socket from the lists as you suggested, maybe adding a
>>> function in af_vsock.c that all transports can call.
>>
>> I'd be happy to submit a proper patch, but it would be helpful to decide
>> how close to AF_INET/AF_UNIX's behaviour is close enough. Or would you
>> rather have that UAF plugged first?
>>
> 
> I'd say, let's fix the UAF first, then fix the behaviour (also in a
> single series, but I prefer 2 separate patches if possible).
> About that, AF_VSOCK was started with the goal of following AF_INET as
> closely as possible, and the test suite should serve that as well, so if
> we can solve this problem and get closer to AF_INET, possibly even
> adding a dedicated test, that would be ideal!

All right, so let's keep the binding and allow removal from (un)bound list
only on socket destruction. This is transport independent, changes are
pretty minimal and, well, keeps the binding. Mixes well with the connect()
behaviour fix.

Let me know what you think:
https://lore.kernel.org/netdev/20250117-vsock-transport-vs-autobind-v1-0-c802c803762d@rbox.co/

Thanks,
Michal


  reply	other threads:[~2025-01-17 22:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-10  8:35 [PATCH net v2 0/5] vsock: some fixes due to transport de-assignment Stefano Garzarella
2025-01-10  8:35 ` [PATCH net v2 1/5] vsock/virtio: discard packets if the transport changes Stefano Garzarella
2025-01-10 22:46   ` Hyunwoo Kim
2025-01-12 22:42   ` Michal Luczaj
2025-01-13  8:57     ` Stefano Garzarella
2025-01-13  9:07       ` Stefano Garzarella
2025-01-13 10:12         ` Michal Luczaj
2025-01-13 11:05           ` Stefano Garzarella
2025-01-13 13:51             ` Michal Luczaj
2025-01-13 15:01               ` Stefano Garzarella
2025-01-14  0:09                 ` Michal Luczaj
2025-01-14 10:16                   ` Stefano Garzarella
2025-01-14 16:31                     ` Michal Luczaj
2025-01-16  8:57                       ` Stefano Garzarella
2025-01-17 22:02                         ` Michal Luczaj [this message]
2025-01-10  8:35 ` [PATCH net v2 2/5] vsock/bpf: return early if transport is not assigned Stefano Garzarella
2025-01-10  8:35 ` [PATCH net v2 3/5] vsock/virtio: cancel close work in the destructor Stefano Garzarella
2025-01-10 10:57   ` Luigi Leonardi
2025-01-10 22:48   ` Hyunwoo Kim
2025-01-10  8:35 ` [PATCH net v2 4/5] vsock: reset socket state when de-assigning the transport Stefano Garzarella
2025-01-10 10:56   ` Luigi Leonardi
2025-01-10 11:25     ` Stefano Garzarella
2025-01-10  8:35 ` [PATCH net v2 5/5] vsock: prevent null-ptr-deref in vsock_*[has_data|has_space] Stefano Garzarella
2025-01-10  9:49   ` Luigi Leonardi
2025-01-10 22:52   ` Hyunwoo Kim
2025-01-14 11:50 ` [PATCH net v2 0/5] vsock: some fixes due to transport de-assignment patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e3085fe8-3dae-40b2-970f-b8cda956a8f5@rbox.co \
    --to=mhal@rbox.co \
    --cc=bpf@vger.kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=eperezma@redhat.com \
    --cc=horms@kernel.org \
    --cc=jasowang@redhat.com \
    --cc=kuba@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=leonardi@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=qwerty@theori.io \
    --cc=sgarzare@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=stefanha@redhat.com \
    --cc=v4bel@theori.io \
    --cc=virtualization@lists.linux.dev \
    --cc=xuanzhuo@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox