linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: "Will Deacon" <will@kernel.org>, "Keir Fraser" <keirf@google.com>,
	"Steven Moreland" <smoreland@google.com>,
	"Frederick Mayle" <fmayle@google.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Stefano Garzarella" <sgarzare@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Eugenio Pérez" <eperezma@redhat.com>,
	netdev@vger.kernel.org, virtualization@lists.linux.dev,
	stable@vger.kernel.org
Subject: [PATCH v3 1/9] vhost/vsock: Avoid allocating arbitrarily-sized SKBs
Date: Mon, 14 Jul 2025 16:20:55 +0100	[thread overview]
Message-ID: <20250714152103.6949-2-will@kernel.org> (raw)
In-Reply-To: <20250714152103.6949-1-will@kernel.org>

vhost_vsock_alloc_skb() returns NULL for packets advertising a length
larger than VIRTIO_VSOCK_MAX_PKT_BUF_SIZE in the packet header. However,
this is only checked once the SKB has been allocated and, if the length
in the packet header is zero, the SKB may not be freed immediately.

Hoist the size check before the SKB allocation so that an iovec larger
than VIRTIO_VSOCK_MAX_PKT_BUF_SIZE + the header size is rejected
outright. The subsequent check on the length field in the header can
then simply check that the allocated SKB is indeed large enough to hold
the packet.

Cc: <stable@vger.kernel.org>
Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff")
Signed-off-by: Will Deacon <will@kernel.org>
---
 drivers/vhost/vsock.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index 802153e23073..66a0f060770e 100644
--- a/drivers/vhost/vsock.c
+++ b/drivers/vhost/vsock.c
@@ -344,6 +344,9 @@ vhost_vsock_alloc_skb(struct vhost_virtqueue *vq,
 
 	len = iov_length(vq->iov, out);
 
+	if (len > VIRTIO_VSOCK_MAX_PKT_BUF_SIZE + VIRTIO_VSOCK_SKB_HEADROOM)
+		return NULL;
+
 	/* len contains both payload and hdr */
 	skb = virtio_vsock_alloc_skb(len, GFP_KERNEL);
 	if (!skb)
@@ -367,8 +370,7 @@ vhost_vsock_alloc_skb(struct vhost_virtqueue *vq,
 		return skb;
 
 	/* The pkt is too big or the length in the header is invalid */
-	if (payload_len > VIRTIO_VSOCK_MAX_PKT_BUF_SIZE ||
-	    payload_len + sizeof(*hdr) > len) {
+	if (payload_len + sizeof(*hdr) > len) {
 		kfree_skb(skb);
 		return NULL;
 	}
-- 
2.50.0.727.gbf7dc18ff4-goog


  reply	other threads:[~2025-07-14 15:21 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-14 15:20 [PATCH v3 0/9] vsock/virtio: SKB allocation improvements Will Deacon
2025-07-14 15:20 ` Will Deacon [this message]
2025-07-15  9:47   ` [PATCH v3 1/9] vhost/vsock: Avoid allocating arbitrarily-sized SKBs Stefano Garzarella
2025-07-14 15:20 ` [PATCH v3 2/9] vsock/virtio: Validate length in packet header before skb_put() Will Deacon
2025-07-15  9:53   ` Stefano Garzarella
2025-07-14 15:20 ` [PATCH v3 3/9] vsock/virtio: Move length check to callers of virtio_vsock_skb_rx_put() Will Deacon
2025-07-15  9:55   ` Stefano Garzarella
2025-07-14 15:20 ` [PATCH v3 4/9] vsock/virtio: Resize receive buffers so that each SKB fits in a 4K page Will Deacon
2025-07-15  9:56   ` Stefano Garzarella
2025-07-14 15:20 ` [PATCH v3 5/9] vsock/virtio: Rename virtio_vsock_alloc_skb() Will Deacon
2025-07-15  9:56   ` Stefano Garzarella
2025-07-14 15:21 ` [PATCH v3 6/9] vsock/virtio: Move SKB allocation lower-bound check to callers Will Deacon
2025-07-15  9:57   ` Stefano Garzarella
2025-07-14 15:21 ` [PATCH v3 7/9] vhost/vsock: Allocate nonlinear SKBs for handling large receive buffers Will Deacon
2025-07-15 10:00   ` Stefano Garzarella
2025-07-14 15:21 ` [PATCH v3 8/9] vsock/virtio: Rename virtio_vsock_skb_rx_put() Will Deacon
2025-07-14 15:21 ` [PATCH v3 9/9] vsock/virtio: Allocate nonlinear SKBs for handling large transmit buffers Will Deacon
2025-07-15 10:01 ` [PATCH v3 0/9] vsock/virtio: SKB allocation improvements Stefano Garzarella
2025-07-15 15:05   ` Will Deacon

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=20250714152103.6949-2-will@kernel.org \
    --to=will@kernel.org \
    --cc=eperezma@redhat.com \
    --cc=fmayle@google.com \
    --cc=jasowang@redhat.com \
    --cc=keirf@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=sgarzare@redhat.com \
    --cc=smoreland@google.com \
    --cc=stable@vger.kernel.org \
    --cc=stefanha@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;
as well as URLs for NNTP newsgroup(s).