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 v3 3/8] vsock/virtio: implement the datagram data path
Date: Fri, 13 Nov 2026 17:47:17 +0000 [thread overview]
Message-ID: <sashiko-outbox-213362@kernel.org> (raw)
In-Reply-To: <20261113-vsock-dgram-support-v3-3-1523c8e9b27e@redhat.com>
Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [High] vsock/virtio: OOB read on filtered nonlinear vhost dgram skb
- [Medium] vsock/virtio: empty datagrams skipped on repeated MSG_PEEK
--
commit 7bb89ea8d31712feb1c6f76854206e10a5fd07b5
Author: Sergio Lopez <slp@redhat.com>
vsock/virtio: implement the datagram data path
This commit adds the VIRTIO_VSOCK_F_DGRAM feature bit and
VIRTIO_VSOCK_TYPE_DGRAM packet type, and implements the common virtio
transport operations to bind, send, and receive datagrams.
> diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
> index 1e762a480df49..08baa1181ba6d 100644
> --- a/net/vmw_vsock/virtio_transport_common.c
> +++ b/net/vmw_vsock/virtio_transport_common.c
[ ... ]
> @@ -999,7 +1018,47 @@ virtio_transport_dgram_dequeue(struct vsock_sock *vsk,
> struct msghdr *msg,
> size_t len, int flags)
> {
> - return -EOPNOTSUPP;
> + struct sock *sk = sk_vsock(vsk);
> + struct virtio_vsock_hdr *hdr;
> + struct sk_buff *skb;
> + size_t payload_len;
> + int err;
> +
> + if (flags & (MSG_OOB | MSG_ERRQUEUE))
> + return -EOPNOTSUPP;
> +
> + skb = skb_recv_datagram(sk, flags, &err);
> + if (!skb)
> + return err;
[Severity: Medium]
Does calling skb_recv_datagram() skip an unread empty datagram when
userspace calls recvmsg() with MSG_PEEK more than once?
Because virtio_vsock_hdr lives in skb headroom, an empty datagram has
skb->len == 0. skb_recv_datagram() passes off = 0 to
__skb_recv_datagram(), which sets peek_at_off = true in
__skb_try_recv_from_queue():
net/core/datagram.c:__skb_try_recv_from_queue() {
...
if (flags & MSG_PEEK) {
if (peek_at_off && _off >= skb->len &&
(_off || skb->peeked)) {
_off -= skb->len;
continue;
}
if (!skb->len) {
skb = skb_set_peeked(skb);
if (unlikely(!skb)) {
*err = -ENOMEM;
return NULL;
}
}
*peeked = 1;
refcount_inc(&skb->users);
} else
...
}
The first MSG_PEEK sets skb->peeked = 1 on the 0-length skb, and the next
MSG_PEEK sees _off >= skb->len && skb->peeked and skips the unread empty
datagram, returning the following datagram out of order or failing with
-EAGAIN. Calling __skb_recv_datagram() with sk_peek_offset(sk, flags)
avoids this, as in commit a0917e0bc6ef ("datagram: When peeking datagrams
with offset < 0 don't skip empty skbs").
[ ... ]
> @@ -1805,6 +1875,38 @@ void virtio_transport_recv_pkt(struct virtio_transport *t,
> goto free_pkt;
> }
>
> + /* Dgram packets are delivered directly to bound sockets without
> + * going through the connection state machine. Undeliverable
> + * datagrams are silently dropped (no RST).
> + */
> + 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_dgram_socket_net(&dst, net);
> +
> + if (!sk)
> + goto free_pkt;
> +
> + vsk = vsock_sk(sk);
> + lock_sock(sk);
> + 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);
[Severity: High]
Can sock_queue_rcv_skb() corrupt a nonlinear vhost-vsock skb when a socket
filter trims the packet, leading to an out-of-bounds read in
virtio_transport_dgram_dequeue()?
In vhost_vsock_alloc_skb(), the skb is allocated from the guest TX
descriptor chain length before hdr->len is inspected, and
virtio_vsock_skb_put() then sets skb->len = payload_len without adjusting
skb->data_len:
include/linux/virtio_vsock.h:virtio_vsock_skb_put() {
if (skb_is_nonlinear(skb))
skb->len = len;
else
skb_put(skb, len);
}
When a guest sends a TX descriptor chain larger than 32 KiB with hdr->len
smaller than the descriptor payload space, the resulting nonlinear skb has
skb->len < skb->data_len and a negative skb_headlen(skb). If the receiving
host datagram socket has a filter attached, sock_queue_rcv_skb() ->
sk_filter_trim_cap() -> pskb_trim() -> ___pskb_trim() treats the negative
skb_headlen(skb) as a large unsigned offset, drops all page frags, zeroes
skb->data_len, and sets skb->tail past skb->end. The subsequent
skb_copy_datagram_iter() in virtio_transport_dgram_dequeue() then copies
skb_shared_info and out-of-bounds kernel heap memory after skb->end to
userspace.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261113-vsock-dgram-support-v3-0-1523c8e9b27e@redhat.com?part=3
next prev parent reply other threads:[~2026-11-13 17:47 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-13 17:15 [PATCH RFC v3 0/8] vsock: add datagram support to virtio and vhost Sergio Lopez
2026-11-13 17:15 ` [PATCH RFC v3 1/8] vsock: expose the core port allocator to transports Sergio Lopez
2026-11-13 17:22 ` sashiko-bot
2026-11-13 17:15 ` [PATCH RFC v3 2/8] vsock: report datagram receive and send queue state Sergio Lopez
2026-11-13 17:25 ` sashiko-bot
2026-11-13 17:15 ` [PATCH RFC v3 3/8] vsock/virtio: implement the datagram data path Sergio Lopez
2026-11-13 17:47 ` sashiko-bot [this message]
2026-11-13 17:15 ` [PATCH RFC v3 4/8] vsock/virtio: negotiate datagram support on the guest Sergio Lopez
2026-11-13 17:35 ` sashiko-bot
2026-11-13 17:15 ` [PATCH RFC v3 5/8] vhost/vsock: negotiate datagram support with guests Sergio Lopez
2026-11-13 17:34 ` sashiko-bot
2026-11-13 17:15 ` [PATCH RFC v3 6/8] vsock: allow datagrams to use directional transports Sergio Lopez
2026-11-13 17:42 ` sashiko-bot
2026-11-13 17:15 ` [PATCH RFC v3 7/8] vsock: fragment datagrams across receive buffers Sergio Lopez
2026-11-13 17:34 ` sashiko-bot
2026-11-13 22:37 ` Bobby Eshleman
2026-11-13 17:15 ` [PATCH RFC v3 8/8] vsock: add datagram tests to vsock_test Sergio Lopez
2026-11-13 17:51 ` sashiko-bot
2026-11-13 22:18 ` [PATCH RFC v3 0/8] vsock: add datagram support to virtio and vhost Bobby Eshleman
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-213362@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.