From: sashiko-bot@kernel.org
To: "Sergio Lopez" <slp@redhat.com>
Cc: virtualization@lists.linux.dev, kvm@vger.kernel.org,
bpf@vger.kernel.org, linux-hyperv@vger.kernel.org,
"Michael S. Tsirkin" <mst@redhat.com>,
"Eugenio Perez" <eperezma@redhat.com>
Subject: Re: [PATCH RFC 5/8] vhost/vsock: negotiate datagram support with guests
Date: Wed, 28 Oct 2026 16:20:54 +0000 [thread overview]
Message-ID: <sashiko-outbox-188158@kernel.org> (raw)
In-Reply-To: <20261028-vsock-dgram-support-v1-5-e457cf7cee78@sinrega.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] vhost/vsock: missing dgram_allow check in vhost_vsock_handle_tx_kick()
--
commit 635912e90dc603f9b7384d44cf174e18056f799d
Author: Sergio Lopez <slp@redhat.com>
vhost/vsock: negotiate datagram support with guests
This commit exposes VIRTIO_VSOCK_F_DGRAM in the vhost feature bitmap and
tracks whether datagram support was negotiated per guest via
vsock->dgram_allow. It also wires up vhost_transport_dgram_allow() to check
the negotiated feature on the target guest for outbound datagrams.
> diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
> index 0cb87971d7491..eb2fbdb721aa9 100644
> --- a/drivers/vhost/vsock.c
> +++ b/drivers/vhost/vsock.c
[ ... ]
> @@ -516,6 +520,24 @@ static bool vhost_transport_seqpacket_allow(struct vsock_sock *vsk,
> return seqpacket_allow;
> }
>
> +static bool vhost_transport_dgram_allow(struct vsock_sock *vsk,
> + u32 cid, u32 port)
> +{
> + struct net *net = sock_net(sk_vsock(vsk));
> + struct vhost_vsock *vsock;
> + bool dgram_allow = false;
> +
> + rcu_read_lock();
> + vsock = vhost_vsock_get(cid, net);
> +
> + if (vsock)
> + dgram_allow = vsock->dgram_allow;
> +
> + rcu_read_unlock();
> +
> + return dgram_allow;
> +}
> +
> static void vhost_vsock_handle_tx_kick(struct vhost_work *work)
> {
> struct vhost_virtqueue *vq = container_of(work, struct vhost_virtqueue,
[Severity: Medium]
Can a guest that has not negotiated VIRTIO_VSOCK_F_DGRAM still send
VIRTIO_VSOCK_TYPE_DGRAM packets to unconnected bound SOCK_DGRAM sockets on
the host?
vhost_transport_dgram_allow() checks vsock->dgram_allow on outbound host
connect() and sendmsg() paths, but on the guest-to-host path in
drivers/vhost/vsock.c:vhost_vsock_handle_tx_kick(), incoming packets are
passed to virtio_transport_recv_pkt() without checking vsock->dgram_allow:
drivers/vhost/vsock.c:vhost_vsock_handle_tx_kick() {
...
/* Only accept correctly addressed packets */
if (le64_to_cpu(hdr->src_cid) == vsock->guest_cid &&
le64_to_cpu(hdr->dst_cid) ==
vhost_transport_get_local_cid())
virtio_transport_recv_pkt(&vhost_transport, skb,
vsock->net);
else
kfree_skb(skb);
...
}
Unlike VIRTIO_VSOCK_TYPE_SEQPACKET, where inbound connection requests go
through virtio_transport_recv_listen() -> vsock_assign_transport() ->
vhost_transport_seqpacket_allow(), inbound VIRTIO_VSOCK_TYPE_DGRAM packets
in net/vmw_vsock/virtio_transport_common.c:virtio_transport_recv_pkt() are
queued directly onto bound unconnected SOCK_DGRAM sockets without calling
dgram_allow():
net/vmw_vsock/virtio_transport_common.c:virtio_transport_recv_pkt() {
...
if (le16_to_cpu(hdr->type) == VIRTIO_VSOCK_TYPE_DGRAM) {
if (le16_to_cpu(hdr->op) != VIRTIO_VSOCK_OP_RW)
goto free_pkt;
sk = vsock_find_bound_socket_net(&dst, net);
...
if (sock_flag(sk, SOCK_DEAD) ||
vsk->transport != &t->transport ||
(sk->sk_socket->state != SS_UNCONNECTED &&
!vsock_check_source(vsk, &t->transport, &src))) {
release_sock(sk);
sock_put(sk);
goto free_pkt;
}
if (sock_queue_rcv_skb(sk, skb))
kfree_skb(skb);
...
}
Even with the later virtio_transport_dgram_source_allow() check, unconnected
bound SOCK_DGRAM sockets return true before consulting dgram_allow().
Should vhost_vsock_handle_tx_kick() drop VIRTIO_VSOCK_TYPE_DGRAM packets
when !vsock->dgram_allow, or should virtio_transport_recv_pkt() validate
dgram_allow() for incoming datagrams regardless of whether the receiving
socket is connected?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261028-vsock-dgram-support-v1-0-e457cf7cee78@sinrega.org?part=5
next prev parent reply other threads:[~2026-10-28 16:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 16:04 [PATCH RFC 0/8] vsock: add datagram support to virtio and vhost Sergio Lopez
2026-10-28 16:04 ` [PATCH RFC 1/8] vsock: expose the core port allocator to transports Sergio Lopez
2026-10-28 16:10 ` sashiko-bot
2026-10-28 16:04 ` [PATCH RFC 2/8] vsock: report datagram receive and send queue state Sergio Lopez
2026-10-28 16:12 ` sashiko-bot
2026-10-28 16:04 ` [PATCH RFC 3/8] vsock/virtio: implement the datagram data path Sergio Lopez
2026-10-28 16:28 ` sashiko-bot
2026-10-28 16:04 ` [PATCH RFC 4/8] vsock/virtio: negotiate datagram support on the guest Sergio Lopez
2026-10-28 16:23 ` sashiko-bot
2026-10-28 16:04 ` [PATCH RFC 5/8] vhost/vsock: negotiate datagram support with guests Sergio Lopez
2026-10-28 16:20 ` sashiko-bot [this message]
2026-10-28 16:04 ` [PATCH RFC 6/8] vsock: allow datagrams to use directional transports Sergio Lopez
2026-10-28 16:34 ` sashiko-bot
2026-10-28 16:04 ` [PATCH RFC 7/8] vsock: preserve host-to-guest datagram boundaries Sergio Lopez
2026-10-28 16:23 ` sashiko-bot
2026-10-28 16:04 ` [PATCH RFC 8/8] vsock: add datagram tests to vsock_test Sergio Lopez
2026-10-28 16:12 ` sashiko-bot
2026-10-28 17:25 ` [PATCH RFC 0/8] vsock: add datagram support to virtio and vhost Alexei Starovoitov
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=sashiko-outbox-188158@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=eperezma@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=mst@redhat.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=slp@redhat.com \
--cc=virtualization@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.