Linux-HyperV List
 help / color / mirror / Atom feed
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

  reply	other threads:[~2026-11-13 17:47 UTC|newest]

Thread overview: 12+ 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:15 ` [PATCH RFC v3 2/8] vsock: report datagram receive and send queue state Sergio Lopez
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:15 ` [PATCH RFC v3 5/8] vhost/vsock: negotiate datagram support with guests Sergio Lopez
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:15 ` [PATCH RFC v3 8/8] vsock: add datagram tests to vsock_test Sergio Lopez
2026-11-13 17:51   ` sashiko-bot

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox