All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Drokin <green@linuxhacker.ru>
To: sgarzare@redhat.com, stefanha@redhat.com, mst@redhat.com
Cc: jasowangio@gmail.com, eperezma@redhat.com,
	xuanzhuo@linux.alibaba.com, bobbyeshleman@meta.com,
	davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org,
	pabeni@redhat.com, horms@kernel.org, netdev@vger.kernel.org,
	virtualization@lists.linux.dev, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH net v2 0/3] vsock/virtio: bound what a peer can make the host queue
Date: Fri,  6 Nov 2026 00:02:41 -0500	[thread overview]
Message-ID: <20261106050244.602625-1-green@linuxhacker.ru> (raw)

A virtio-vsock peer that does not consume what it is sent can make the
local side queue memory that no limit covers. On a host the peer is a
guest, and the memory is GFP_KERNEL, charged to no memory cgroup. Two
ways remain on net/main:

 - the send credit trusts the fwd_cnt the peer reports, so a peer that
   never reads but keeps acknowledging gets unlimited credit (patch 2);
 - credit updates are not bounded at all: a peer can solicit them with
   OP_CREDIT_REQUEST, or by sending small packets that a reader drains,
   while posting no rx buffers (patch 3). The same works against a
   guest whose device stops reading the tx virtqueue.

Patch 1 fixes the accounting of packets that vhost drops on rx errors;
patch 2 relies on bytes_unsent being right.

These were found by an LLM-assisted security review of vhost-vsock,
done while porting a project from Xen to KVM. Patches 2 and 3 were
reproduced (below); the error paths of patch 1 were not, as they need a
guest that posts malformed rx buffers. The same review found the
receive skb sizing problem that Daehyeon Ko independently fixed in
d5e912448cd9 ("vhost/vsock: size receive SKBs from declared payload"),
so that part is not in this series.

Nothing changes on the wire, except that fewer credit updates are sent.

Tested in an x86_64 qemu/KVM guest running the kernel under test
(net/main fafbc4051123). For the host side, the "guest" is a user-space
program driving /dev/vhost-vsock directly, talking to plain AF_VSOCK
host sockets. For the guest side, a nested guest running the same
kernel uses a vhost-user vsock device that stops reading its tx
virtqueue:

  case                                      net/main      this series
  lying fwd_cnt, no rx buffers, 2 s of      256 MiB       256 KiB
  non-blocking send() on one socket         queued        (one window)
  20000 OP_CREDIT_REQUEST, no rx buffers    +18.5 MiB     +0
  20000 1-byte packets, each read by host   +18.1 MiB     +24 KiB
  guest, tx virtqueue full, 200             200 credit    2
  OP_CREDIT_REQUEST on one connection       updates

vsock_test from tools/testing/vsock passes over loopback and between a
nested guest and its host. A bidirectional stress test (up to 512
connections streaming both ways, readers draining in small reads) runs
without stalls, and vsock_perf throughput stays within run-to-run noise.
A test that moves sockets between transports in connect() while their
packets are queued passes. With KASAN and lockdep enabled, these tests
show no reports.

The reproducers (a user-space program that drives /dev/vhost-vsock as
the guest, and the vhost-user device) are available on request.

Changes in v2:
 - patch 3: fold a new credit update into the one the socket already has
   queued, rewriting its header under the queue lock, instead of
   tracking it from virtio_vsock_sock with a refcount, an skb destructor
   and transmit hooks (review). vhost and the guest driver are no longer
   touched. A failed add to a full guest tx virtqueue no longer lets
   another update through (Sashiko).
 - patch 2: commit message only, the writer's wakeup is gated by
   sock_writeable().
 - all patches: say how the issues were found; patch 3 gives its test
   results.
 - rebased on net/main fafbc4051123.

v1: https://lore.kernel.org/netdev/20261105000141.3617241-1-green@linuxhacker.ru/

Oleg Drokin (3):
  vhost/vsock: release the accounting of packets dropped on rx errors
  vsock/virtio: bound the send credit by bytes not yet consumed by the
    transport
  vsock/virtio: fold credit updates into the one a socket has queued

 drivers/vhost/vsock.c                   | 23 +++++++--
 include/linux/virtio_vsock.h            | 66 ++++++++++++++++++++++++-
 include/net/af_vsock.h                  |  6 +++
 net/vmw_vsock/virtio_transport_common.c |  8 ++-
 net/vmw_vsock/vsock_loopback.c          |  2 +
 5 files changed, 98 insertions(+), 7 deletions(-)

-- 
2.56.0


             reply	other threads:[~2026-11-06  5:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06  5:02 Oleg Drokin [this message]
2026-11-06  5:02 ` [PATCH net v2 1/3] vhost/vsock: release the accounting of packets dropped on rx errors Oleg Drokin
2026-11-12 14:21   ` Stefano Garzarella
2026-11-06  5:02 ` [PATCH net v2 2/3] vsock/virtio: bound the send credit by bytes not yet consumed by the transport Oleg Drokin
2026-11-12 14:31   ` Stefano Garzarella
2026-11-06  5:02 ` [PATCH net v2 3/3] vsock/virtio: fold credit updates into the one a socket has queued Oleg Drokin
2026-11-12 14:48   ` Stefano Garzarella

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=20261106050244.602625-1-green@linuxhacker.ru \
    --to=green@linuxhacker.ru \
    --cc=bobbyeshleman@meta.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=eperezma@redhat.com \
    --cc=horms@kernel.org \
    --cc=jasowangio@gmail.com \
    --cc=kuba@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sgarzare@redhat.com \
    --cc=stefanha@redhat.com \
    --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 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.