From nobody Sun Feb 8 06:04:49 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E495F47DD55 for ; Wed, 21 Jan 2026 09:36:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768988202; cv=none; b=vGBqvVJeoYzviA6emEDJIOHKs64+HHGZ3joaAYRT3W5+oUCV5mugvK+US9k9f+xkTX3I8Uh82hxqAhc6NRM1wq+M8OZxizZYjO9c6u3HUt7LDJlGJ+f0XpS4K5yIYPdcqJjn46RQ8SOlJYj8najWknKaS7oY9U//HGnVfdFAc70= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768988202; c=relaxed/simple; bh=QU6xQfM9f00ZpwjUsd6GPQ+PxU3JVUFFAWJJEmaV/o0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gPkwBtVRDy5hdvC7bvRetbVtaHI9YVV7B5S4KMJOzbvmaWoFDEaz3pTpUWupvCpoUvV4UveP63TqA+2NKYwLRETsY81YBP8zHAhOMz20MJU+jq+MVMCVrrJww96VkACY/0NtO1TmOgGshwL0iCq+0muvR3INVk2Ta2No5374kS4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=cdZZq3Y8; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=mBOWZvf4; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="cdZZq3Y8"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="mBOWZvf4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768988199; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7DV1XJTkbFynFHoZNtzuqUf26Hx/N2mSbX7HPLgi2JE=; b=cdZZq3Y8WETJZIDNagRnmx1CA721fBg7aSNzrfQ/sGuVCm801X+3TO9ZMAmw/HSabXoEvQ x6YmIqAc+I0jGD0RnUBe2jGBQn5DyhEvmLXkkWdGirUWwlCuPwWsVymCVC9bE18dJHg3EH vjAJHccL4tCzh0y/Ws/xymwvHv0yNxo= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-564-YWG4sKczMFeLlrmh_8ZMWw-1; Wed, 21 Jan 2026 04:36:38 -0500 X-MC-Unique: YWG4sKczMFeLlrmh_8ZMWw-1 X-Mimecast-MFC-AGG-ID: YWG4sKczMFeLlrmh_8ZMWw_1768988197 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-47ee868f5adso48978715e9.0 for ; Wed, 21 Jan 2026 01:36:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1768988197; x=1769592997; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=7DV1XJTkbFynFHoZNtzuqUf26Hx/N2mSbX7HPLgi2JE=; b=mBOWZvf4/lGHrh3XqrfKWkliWdWejnSk88BhDi+tWVE5NQjr1CO/QSXEiszUfg6+jr SuObPYERvU4XR2R1PrXsHon+dROyaSJsw2SXKDe6bFRvvGkDOl24gGXUerXdvweaRYN4 H3nMXTPTnq9pmSVM49HF2OcYrmaqHlakD7QAc5eW3AYFkcZCgxFpSqabManMkL6StVw/ hzVAuW/xzR/mAVkDfEH+aq6CVlbFvMaiuPE68BPsyaEoSCIOQ8WYxNKWLYN+TueBUzDC 6NOVQWqbjtrDHny/JB70RE1AXCPB5lWI1IL/n36qX9231+3LKO4UWrOjA+RYqZA7dNpM Eifw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768988197; x=1769592997; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=7DV1XJTkbFynFHoZNtzuqUf26Hx/N2mSbX7HPLgi2JE=; b=U+Dstpaq4yZz4N1DY9CBLlt2doSp9RHYNYGlRSB+pSrDGca4M4U1nP5mZxQh0OKxkW GoJo99qlSaSqRbgMFErye/hOQ3NjgfcrVDF21eoNMV0DE8LDccEnbwItwSdaDF/I1pT7 943RAqKMbDFMDuLOJpGC63Y1S55cF1jwytLuD6iAsBDMz8j4O+5VS5ULg29NsF7WJT1T qBVtiYFE4yC4CER3OvGMDsuMp9DJbML+iFywK2u65lIOCfvlr7V8XBEFSU7x/UKwbfr3 lBj2ZaUaE0Ic9cd0I24lJTrCjGe1wxL86L7nJBbqmXapG8M/IB+dlCg3g3ypVtAin63P DKcA== X-Forwarded-Encrypted: i=1; AJvYcCW8dSlwdMAeuyZcUlrQZIFbEDGemh8rG/XDFrPAjx1OU/oUBeBTqncBxT7VFigI9si6atvO2ESBWMXqKCQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yyc9YIbrZx5TkREfe3wfVzy0ANobf3d5TzzYCVe75YItYTo2aPD 07er9GDxiwhtWeGm53csH99RzoOMUaYN1GDQVM/Rq7p/uhxx94LwwPYxzBuPLTgzYIVprQZZpUC 2wCgPslhNP8CJ+iYkZhKIPfQri5sc4OsSvFT1odA66XHayARQEyyJ3Je8CZ1lgPw2Tw== X-Gm-Gg: AZuq6aIkB3vY40XfDZzM+Bbh/MlhNVIPPYAqKq4ndTps/eA3iYLlcdyCQxyOaSof5eC cI42ijnqjsgJLdFKAlpGS7IpgY/SZaTW6WDYjAcvHDwtB2y65Vho5x3toqiN51MwXTY2kvxTkGg M76mpWgQfkTMY9HGWh6PLeCz+6ya2WBe1QEqzM2rdmAWxRGb+laTCAiTH9lH0UCVqPVPEwa91uY 22Q/ifwZRpS5UBK6wIO9+T5gJyYdN124L1VcVYNoyNUHfttiTQ/NhaOdVxVwgABCuwXYmo0ekzs x7cBtnrPgMyIYv9mJ2y6aRR6CZj0ch5B/Ol2AfEZAyoccyLdenT3cvKOM7SvAIiOggQNd2ghs+J ae7Yc2fR8tEw6dIQzp1ynA4O4L+qfw7jbfWjKtvzGxIsMWuP+BF3K2bvB4/EL X-Received: by 2002:a05:600c:5493:b0:480:3a71:92b2 with SMTP id 5b1f17b1804b1-4803a71968bmr114132485e9.26.1768988197316; Wed, 21 Jan 2026 01:36:37 -0800 (PST) X-Received: by 2002:a05:600c:5493:b0:480:3a71:92b2 with SMTP id 5b1f17b1804b1-4803a71968bmr114131865e9.26.1768988196858; Wed, 21 Jan 2026 01:36:36 -0800 (PST) Received: from stex1.redhat.com (host-82-53-134-58.retail.telecomitalia.it. [82.53.134.58]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43595e0a6fasm7161626f8f.10.2026.01.21.01.36.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jan 2026 01:36:35 -0800 (PST) From: Stefano Garzarella To: netdev@vger.kernel.org Cc: Simon Horman , Eric Dumazet , "Michael S. Tsirkin" , Arseniy Krasnov , "David S. Miller" , Stefano Garzarella , virtualization@lists.linux.dev, Paolo Abeni , Jakub Kicinski , Stefan Hajnoczi , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Claudio Imbrenda , Jason Wang , Xuan Zhuo , =?UTF-8?q?Eugenio=20P=C3=A9rez?= , Asias He , Melbin K Mathew Subject: [PATCH net v6 1/4] vsock/virtio: fix potential underflow in virtio_transport_get_credit() Date: Wed, 21 Jan 2026 10:36:25 +0100 Message-ID: <20260121093628.9941-2-sgarzare@redhat.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260121093628.9941-1-sgarzare@redhat.com> References: <20260121093628.9941-1-sgarzare@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Melbin K Mathew The credit calculation in virtio_transport_get_credit() uses unsigned arithmetic: ret =3D vvs->peer_buf_alloc - (vvs->tx_cnt - vvs->peer_fwd_cnt); If the peer shrinks its advertised buffer (peer_buf_alloc) while bytes are in flight, the subtraction can underflow and produce a large positive value, potentially allowing more data to be queued than the peer can handle. Reuse virtio_transport_has_space() which already handles this case and add a comment to make it clear why we are doing that. Fixes: 06a8fc78367d ("VSOCK: Introduce virtio_vsock_common.ko") Suggested-by: Stefano Garzarella Signed-off-by: Melbin K Mathew [Stefano: use virtio_transport_has_space() instead of duplicating the code] [Stefano: tweak the commit message] Signed-off-by: Stefano Garzarella Acked-by: Michael S. Tsirkin Reviewed-by: Luigi Leonardi --- net/vmw_vsock/virtio_transport_common.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio= _transport_common.c index 26b979ad71f0..6175124d63d3 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_common.c @@ -28,6 +28,7 @@ =20 static void virtio_transport_cancel_close_work(struct vsock_sock *vsk, bool cancel_timeout); +static s64 virtio_transport_has_space(struct virtio_vsock_sock *vvs); =20 static const struct virtio_transport * virtio_transport_get_ops(struct vsock_sock *vsk) @@ -499,9 +500,7 @@ u32 virtio_transport_get_credit(struct virtio_vsock_soc= k *vvs, u32 credit) return 0; =20 spin_lock_bh(&vvs->tx_lock); - ret =3D vvs->peer_buf_alloc - (vvs->tx_cnt - vvs->peer_fwd_cnt); - if (ret > credit) - ret =3D credit; + ret =3D min_t(u32, credit, virtio_transport_has_space(vvs)); vvs->tx_cnt +=3D ret; vvs->bytes_unsent +=3D ret; spin_unlock_bh(&vvs->tx_lock); @@ -877,11 +876,14 @@ u32 virtio_transport_seqpacket_has_data(struct vsock_= sock *vsk) } EXPORT_SYMBOL_GPL(virtio_transport_seqpacket_has_data); =20 -static s64 virtio_transport_has_space(struct vsock_sock *vsk) +static s64 virtio_transport_has_space(struct virtio_vsock_sock *vvs) { - struct virtio_vsock_sock *vvs =3D vsk->trans; s64 bytes; =20 + /* Use s64 arithmetic so if the peer shrinks peer_buf_alloc while + * we have bytes in flight (tx_cnt - peer_fwd_cnt), the subtraction + * does not underflow. + */ bytes =3D (s64)vvs->peer_buf_alloc - (vvs->tx_cnt - vvs->peer_fwd_cnt); if (bytes < 0) bytes =3D 0; @@ -895,7 +897,7 @@ s64 virtio_transport_stream_has_space(struct vsock_sock= *vsk) s64 bytes; =20 spin_lock_bh(&vvs->tx_lock); - bytes =3D virtio_transport_has_space(vsk); + bytes =3D virtio_transport_has_space(vvs); spin_unlock_bh(&vvs->tx_lock); =20 return bytes; @@ -1492,7 +1494,7 @@ static bool virtio_transport_space_update(struct sock= *sk, spin_lock_bh(&vvs->tx_lock); vvs->peer_buf_alloc =3D le32_to_cpu(hdr->buf_alloc); vvs->peer_fwd_cnt =3D le32_to_cpu(hdr->fwd_cnt); - space_available =3D virtio_transport_has_space(vsk); + space_available =3D virtio_transport_has_space(vvs); spin_unlock_bh(&vvs->tx_lock); return space_available; } --=20 2.52.0 From nobody Sun Feb 8 06:04:49 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B77E147DFA7 for ; Wed, 21 Jan 2026 09:36:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768988208; cv=none; b=es1FhglEV6Mb0nCZVbt2YZIT5LPda+tsGIqYhp4CKpPb6+SGhHX1SMM1kUKunOe5lzDNrcEH3C0ZCSZ62ML79YIE0gw9GxgaitDDPvsP8S/7sHz+4Al4wTaNEqfR7SV6VPsa3DGma68G2mLdUd+eiN9TC7ltDZcaLtCZn+/Scck= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768988208; c=relaxed/simple; bh=PcAOc3r6px2QPynOOTZs4aSgXDaZ3NGUJGTa4O51yqg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SrVR+hto46K7PmzutKRqniILV5rahyxdb/g2nbE7YcfmVWCuZGoeNKs2ewK/FYXb8EqmhFI+nn8Yy1DDYBPp7EM1sSljDXUgDhNeQZw1YD5p4kLatr55xWoXkMZ1zn1w3/1mEBsag7uwlPfxxXaeTIfmCNqYFFvGSv73ZOdZtD0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=ITou7ufz; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=jr0qjS68; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ITou7ufz"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="jr0qjS68" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768988205; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6zDKTURxMpN1giCRjW7fiv4qni6ys721eKds24IdkTk=; b=ITou7ufzLDLpgwlVKRe57PAI4bzmFefP7nf27m17TkKArI68+ekv/qx6J2ORCpcJVKQ4oB hnXQEHZUlKTbvVeX3EWMptWBVGw9jmFuzIEdqAurMnCP0NqJcp108EjVeDIVnBfDzJWcTc BSezKEzhxjJi6885or+5/m8yrF8NJP0= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-99-0AmalRS4OP2_LpOEWG1-2Q-1; Wed, 21 Jan 2026 04:36:43 -0500 X-MC-Unique: 0AmalRS4OP2_LpOEWG1-2Q-1 X-Mimecast-MFC-AGG-ID: 0AmalRS4OP2_LpOEWG1-2Q_1768988202 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4803e8b6007so10777555e9.0 for ; Wed, 21 Jan 2026 01:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1768988202; x=1769593002; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=6zDKTURxMpN1giCRjW7fiv4qni6ys721eKds24IdkTk=; b=jr0qjS68OTXX6cjhVTpCkO7OLdYWpUuRWINo10x7ukf2qK1cR/ccKfpX/RSJ4NVG0z 7I/683TLPuLTd1UWqbfxATGk3754DZnh8OwvEx4ch1QdNCqhRE84n5HOtkr7lWWrqiEC qSyExrykmqjoMSX46zMYGpUFY3EXgGj1Y2t6NbApKnItpv/5RgrkBC7FN3HCj/BLolT6 8cMXnna2YXmKzp1VX4etTRfnk/4bHt9JintAMr2IB1GJvTBhWDsLB5MoFlC2Nz8PYxBf nX2HwebYUxxDUit50txv8Q2FJ/23A3lB97gq0dlaRzffEqM+6364tflpL8RNraeV+WjT +u6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768988202; x=1769593002; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=6zDKTURxMpN1giCRjW7fiv4qni6ys721eKds24IdkTk=; b=VAWrojZV6ClDmJMkr+i8k+XtHZXderZROGzMtoypejT5ukl6pGreC4JzDn+2f/27NL s0ULjAoUkOEZI+WaBSYTA6ieDs0kYb35O4YfM5q2uhfKvc83yAjG7mIjIA62OdJQquux 7nzA5zZqYPvosgTz2XcIh3DnzAlGSh+FzZ91zPnWsykjxb/yWt80zW2/+fQMcxt/dwZP JxP7IohfqP4YUO2a1Ih7HEImBJ1TJ96FXt4smpt0x1tHhlgpyQu6/6sBk3OEtp/BqCQl w7FE2MhNmv8YvnbHNSwbXmisZg2pGYmebK6Vw7tJsifCe5NpLU2yh8EmJE1+EKrWxcKs 2VWA== X-Forwarded-Encrypted: i=1; AJvYcCUadFQEaVq9VaPQwyP4HQqL/0jzOgCuE6YzqZQdi5VXRww7z5aYDn8XBzGwJ6Bf/SEI7ftqrncP+zuvuWU=@vger.kernel.org X-Gm-Message-State: AOJu0YwSyGoeW1abumpJAZrAINaxOB7vL1iTuMb9UatnkJKVG1/H3eBB UoG5Y4nCGUIZkwEwCpCIHDMbj1b+rhA4BfXtk8uZulYoczbj6t51/h0hbaImmnNhbVJeh3+GbXZ QhOzwQmQfR7mtmseJTz60MH6p5KyotRITIA0tlub2e70411pRdGlAsTM9o/AdX4e8sA== X-Gm-Gg: AZuq6aLFp7LIDmJELA1zji2n5rNrIr2reA6uYJuzuhK+ggUKMHfMMD/rURZDhuEcHbz f4noJij9J33S9aQ/zfUX1XIyqljuqPqNchtDREUGrJlnl/9R4dFnItj9fB0BD/UcPxwNMWlgMoH HmL0QGuiD4Z349hxCpeNZ0YqUWOF0GycNsQGPH18gA5QQULZC3vOuHcFz5/JejjDDXV76QLYJjZ Xt+S2yIRaCDg9876olwz+fo31rmFGN9o8tZv2vVX56Zvp//E/+STCGYyAlhBqxjV+XOMgvohDdH H9GOvAztcZjhilwKvpOjAjJ3ZmcCurnEFtR/driavzNTmGdHClCBJv1LMOBZuqLsm+bMrnXHXme 4stC9Rdj4OJYKutsAiZ0FEHEY7h4Rf0RBIGMJVL7eHJXZFkkcF1QbjkCrEvEM X-Received: by 2002:a05:600c:3e0d:b0:479:3a86:dc1c with SMTP id 5b1f17b1804b1-4803e803c1amr77560815e9.36.1768988202218; Wed, 21 Jan 2026 01:36:42 -0800 (PST) X-Received: by 2002:a05:600c:3e0d:b0:479:3a86:dc1c with SMTP id 5b1f17b1804b1-4803e803c1amr77560335e9.36.1768988201797; Wed, 21 Jan 2026 01:36:41 -0800 (PST) Received: from stex1.redhat.com (host-82-53-134-58.retail.telecomitalia.it. [82.53.134.58]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47f42907141sm355976705e9.9.2026.01.21.01.36.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jan 2026 01:36:40 -0800 (PST) From: Stefano Garzarella To: netdev@vger.kernel.org Cc: Simon Horman , Eric Dumazet , "Michael S. Tsirkin" , Arseniy Krasnov , "David S. Miller" , Stefano Garzarella , virtualization@lists.linux.dev, Paolo Abeni , Jakub Kicinski , Stefan Hajnoczi , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Claudio Imbrenda , Jason Wang , Xuan Zhuo , =?UTF-8?q?Eugenio=20P=C3=A9rez?= , Asias He Subject: [PATCH net v6 2/4] vsock/test: fix seqpacket message bounds test Date: Wed, 21 Jan 2026 10:36:26 +0100 Message-ID: <20260121093628.9941-3-sgarzare@redhat.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260121093628.9941-1-sgarzare@redhat.com> References: <20260121093628.9941-1-sgarzare@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Stefano Garzarella The test requires the sender (client) to send all messages before waking up the receiver (server). Since virtio-vsock had a bug and did not respect the size of the TX buffer, this test worked, but now that we are going to fix the bug, the test hangs because the sender would fill the TX buffer before waking up the receiver. Set the buffer size in the sender (client) as well, as we already do for the receiver (server). Fixes: 5c338112e48a ("test/vsock: rework message bounds test") Signed-off-by: Stefano Garzarella Acked-by: Michael S. Tsirkin --- tools/testing/vsock/vsock_test.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_t= est.c index 27e39354499a..668fbe9eb3cc 100644 --- a/tools/testing/vsock/vsock_test.c +++ b/tools/testing/vsock/vsock_test.c @@ -351,6 +351,7 @@ static void test_stream_msg_peek_server(const struct te= st_opts *opts) =20 static void test_seqpacket_msg_bounds_client(const struct test_opts *opts) { + unsigned long long sock_buf_size; unsigned long curr_hash; size_t max_msg_size; int page_size; @@ -363,6 +364,16 @@ static void test_seqpacket_msg_bounds_client(const str= uct test_opts *opts) exit(EXIT_FAILURE); } =20 + sock_buf_size =3D SOCK_BUF_SIZE; + + setsockopt_ull_check(fd, AF_VSOCK, SO_VM_SOCKETS_BUFFER_MAX_SIZE, + sock_buf_size, + "setsockopt(SO_VM_SOCKETS_BUFFER_MAX_SIZE)"); + + setsockopt_ull_check(fd, AF_VSOCK, SO_VM_SOCKETS_BUFFER_SIZE, + sock_buf_size, + "setsockopt(SO_VM_SOCKETS_BUFFER_SIZE)"); + /* Wait, until receiver sets buffer size. */ control_expectln("SRVREADY"); =20 --=20 2.52.0 From nobody Sun Feb 8 06:04:49 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D0A2947ECD4 for ; Wed, 21 Jan 2026 09:36:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768988213; cv=none; b=j9Y+lYz71lI52BTjtVNPnwPMsBxaJzlB5IBz+DreAZtU5rz/H7Bk37EZqWLPFfbdI6mn2DIGpWc4KhjWAGKjpDy8DOjTZATWzM6NtlOmHcY9JR76kTqyYf1bI+9CKXG4OpCWHktV5hPf0NvPBBTNOjWr1ImRIMbPsyRlnvQ4Ohg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768988213; c=relaxed/simple; bh=8FWDPO7w394Nl7XKsuUojlhzUFs0e7ivz29bXEwBdFU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BfLoS9FWwkKB4lkIoIXIAMjIPKtClJAQ+vBDLi6pa1cCgMjA0zXOmdlkpkd1JgnbHzNTu6jIXZcefulQt91Zd2FS8uxmEPviyamIOl4o+ac4t29m2+Tq7P7gJC++UoDIg9lwNKfFkzd7I8VAMjQaHVdxHqPPIJMX7ab7qEw/Fag= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=TCNpCKQX; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=FsEW//E2; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="TCNpCKQX"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="FsEW//E2" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768988210; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xGM0zHbdn0V12NgombpaBR+rEA6S/BsSNVQrMd4WoM4=; b=TCNpCKQXLnMOks5bMqZAJ4IcqtJ38t1OYTT/zmFHOzMsLVbAgJa8CrnksFobDbD40Bq4bU j77PBp5+UqWzgb7tyP6SMb/QWmQbPSAiKJ/NIc08FRyiO4PxFOhrjFWQ+RxgsqjdZSynbF p60xgQ+5IFRV8FpO4tV8Hlmusm88L9c= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-329-phdWjm1uN4asIBdcsFTm_g-1; Wed, 21 Jan 2026 04:36:48 -0500 X-MC-Unique: phdWjm1uN4asIBdcsFTm_g-1 X-Mimecast-MFC-AGG-ID: phdWjm1uN4asIBdcsFTm_g_1768988207 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-430f5dcd4cdso4112357f8f.2 for ; Wed, 21 Jan 2026 01:36:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1768988207; x=1769593007; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=xGM0zHbdn0V12NgombpaBR+rEA6S/BsSNVQrMd4WoM4=; b=FsEW//E2u1CEsxjYG47z7hsFynDqounY7IdwZW24zQaclAiWtsfM5UcxlCFS1JphxT AtCTetfCd17QqNt29EWVx9OjGolE1MrPdIbp5O796bG1CSiJU7jSCjDWGnRQuBS5PesS oG68+iv8SH7RViyxR5hZC4LM5T81iTB8fZA7ae/rClGahaLTtbyRNDytRt18Wg3AYUbO 1ytf8O77MIp5OieEl/V5A/TBRRMsVakO1zPFCFtyv2phuSICyfC4W0gA2YDcAJ4e19z+ SmeDwu7/Tso7TAKQX5HUSKIjR4yjFbyVBVRgi8fi35EkdSyrtIzu29cNY30/wHZr0O3k SRUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768988207; x=1769593007; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=xGM0zHbdn0V12NgombpaBR+rEA6S/BsSNVQrMd4WoM4=; b=QClwjSb7O303B6ARCTfwzx9E0eYnRqoX9iRHCjESOENvX92RojZu9UVc4qJxKp9XxW 7RlmP3MZO0Wg1zhi+ldrqPflapMiW/WCF59n/K3be4N8ZKBxFxSShbGlaCgOgDK7tdnO kfU48G22NYywoOhruNwAXY6xXRRDXS7cfNm7eTw96J/iV8YppEA1tdLvjnk7tAQPcMVO e23doEFX7PDBDU5li/Ce56Vz1SvTMRVmqLTES81yC1cDQjoGuj3ZlnRypWiX6HcH7dHR PtEgc3jvkREtO8g0aQ6LLtFxjtj/eS10QYZA8aWyzhmd9sck0oFnyZEyJOP1SSHd6CZy RMKw== X-Forwarded-Encrypted: i=1; AJvYcCWNR1lyxourN37uLBeVXD+f83+G9mX2rKM2VbMSTRCgtEG3UeK8IGbbhDj8dmZNU4y12E7e2posiiggpUY=@vger.kernel.org X-Gm-Message-State: AOJu0YwDRgoT0cGUGw1EZr4iwZvHyNOijV0zkUIpTyOKLxRDTimOoR/O UE6pw2EwqeXPjDXaoc00voSJV6wXmS9VoeKRqSk/Vb0R2qz7tFiOUBlUtdWKYy4nZXfVBCvUZeI S8PLsQMv3Nhy2VcWDSGT4lqwVlRNkTGOjoAGVtbesWwWUnQB0qVekAYEnKVxXcbRu3Q== X-Gm-Gg: AZuq6aK2S8CG6V26tmkVFcDgI0OSBzkeybNbueOUeqLZs8bKPeT/Gba42WwEBCO7QK7 aulmz45Zn4tihmnCyZWk5rkMPq1qpi3S5EAogPgB+pE42LQ0+Hk0fyIFwlzFwziM/QC/SKAhK2n NNaDrMiydClhi7OYVkPHU2UXMMLIvPfAEhXkRiFSKFi0jNHVgi98GZq0ssUd6g5F0JIHEKlUxR5 OYFhPGlv1hQ8dt1FfgPxRVH13kQkX/pRMcYcHrpb9ZOlKA2wkFuwPf7mBSv0lBbOstgynDTU6Vh yiS3X2JsTKM3injds157SWIE3d9w8u76Qb9vGeoM+fYwM2PW52bwjUIDdG5e7h9RveTCsyrre4w BWr0XUngqafFoU9IDABDZxywWgVTWOUqLOpHBBgBf2/mFWm2zq4HX5G4P2fDh X-Received: by 2002:a05:6000:18b:b0:435:94c4:649c with SMTP id ffacd0b85a97d-43594c4658bmr4628405f8f.30.1768988207199; Wed, 21 Jan 2026 01:36:47 -0800 (PST) X-Received: by 2002:a05:6000:18b:b0:435:94c4:649c with SMTP id ffacd0b85a97d-43594c4658bmr4628374f8f.30.1768988206674; Wed, 21 Jan 2026 01:36:46 -0800 (PST) Received: from stex1.redhat.com (host-82-53-134-58.retail.telecomitalia.it. [82.53.134.58]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569921da2sm35389534f8f.1.2026.01.21.01.36.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jan 2026 01:36:45 -0800 (PST) From: Stefano Garzarella To: netdev@vger.kernel.org Cc: Simon Horman , Eric Dumazet , "Michael S. Tsirkin" , Arseniy Krasnov , "David S. Miller" , Stefano Garzarella , virtualization@lists.linux.dev, Paolo Abeni , Jakub Kicinski , Stefan Hajnoczi , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Claudio Imbrenda , Jason Wang , Xuan Zhuo , =?UTF-8?q?Eugenio=20P=C3=A9rez?= , Asias He , Melbin K Mathew Subject: [PATCH net v6 3/4] vsock/virtio: cap TX credit to local buffer size Date: Wed, 21 Jan 2026 10:36:27 +0100 Message-ID: <20260121093628.9941-4-sgarzare@redhat.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260121093628.9941-1-sgarzare@redhat.com> References: <20260121093628.9941-1-sgarzare@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Melbin K Mathew The virtio transports derives its TX credit directly from peer_buf_alloc, which is set from the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value. On the host side this means that the amount of data we are willing to queue for a connection is scaled by a guest-chosen buffer size, rather than the host's own vsock configuration. A malicious guest can advertise a large buffer and read slowly, causing the host to allocate a correspondingly large amount of sk_buff memory. The same thing would happen in the guest with a malicious host, since virtio transports share the same code base. Introduce a small helper, virtio_transport_tx_buf_size(), that returns min(peer_buf_alloc, buf_alloc), and use it wherever we consume peer_buf_alloc. This ensures the effective TX window is bounded by both the peer's advertised buffer and our own buf_alloc (already clamped to buffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peer cannot force the other to queue more data than allowed by its own vsock settings. On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with 32 guest vsock connections advertising 2 GiB each and reading slowly drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only recovered after killing the QEMU process. That said, if QEMU memory is limited with cgroups, the maximum memory used will be limited. With this patch applied: Before: MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB After 32 high-credit connections: MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim: ~152 MiB Only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest remains responsive. Compatibility with non-virtio transports: - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per socket based on the local vsk->buffer_* values; the remote side cannot enlarge those queues beyond what the local endpoint configured. - Hyper-V's vsock transport uses fixed-size VMBus ring buffers and an MTU bound; there is no peer-controlled credit field comparable to peer_buf_alloc, and the remote endpoint cannot drive in-flight kernel memory above those ring sizes. - The loopback path reuses virtio_transport_common.c, so it naturally follows the same semantics as the virtio transport. This change is limited to virtio_transport_common.c and thus affects virtio-vsock, vhost-vsock, and loopback, bringing them in line with the "remote window intersected with local policy" behaviour that VMCI and Hyper-V already effectively have. Fixes: 06a8fc78367d ("VSOCK: Introduce virtio_vsock_common.ko") Suggested-by: Stefano Garzarella Signed-off-by: Melbin K Mathew [Stefano: small adjustments after changing the previous patch] [Stefano: tweak the commit message] Signed-off-by: Stefano Garzarella Acked-by: Michael S. Tsirkin Reviewed-by: Luigi Leonardi --- net/vmw_vsock/virtio_transport_common.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio= _transport_common.c index 6175124d63d3..d3e26025ef58 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_common.c @@ -821,6 +821,15 @@ virtio_transport_seqpacket_dequeue(struct vsock_sock *= vsk, } EXPORT_SYMBOL_GPL(virtio_transport_seqpacket_dequeue); =20 +static u32 virtio_transport_tx_buf_size(struct virtio_vsock_sock *vvs) +{ + /* The peer advertises its receive buffer via peer_buf_alloc, but we + * cap it to our local buf_alloc so a remote peer cannot force us to + * queue more data than our own buffer configuration allows. + */ + return min(vvs->peer_buf_alloc, vvs->buf_alloc); +} + int virtio_transport_seqpacket_enqueue(struct vsock_sock *vsk, struct msghdr *msg, @@ -830,7 +839,7 @@ virtio_transport_seqpacket_enqueue(struct vsock_sock *v= sk, =20 spin_lock_bh(&vvs->tx_lock); =20 - if (len > vvs->peer_buf_alloc) { + if (len > virtio_transport_tx_buf_size(vvs)) { spin_unlock_bh(&vvs->tx_lock); return -EMSGSIZE; } @@ -884,7 +893,8 @@ static s64 virtio_transport_has_space(struct virtio_vso= ck_sock *vvs) * we have bytes in flight (tx_cnt - peer_fwd_cnt), the subtraction * does not underflow. */ - bytes =3D (s64)vvs->peer_buf_alloc - (vvs->tx_cnt - vvs->peer_fwd_cnt); + bytes =3D (s64)virtio_transport_tx_buf_size(vvs) - + (vvs->tx_cnt - vvs->peer_fwd_cnt); if (bytes < 0) bytes =3D 0; =20 --=20 2.52.0 From nobody Sun Feb 8 06:04:49 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B83A447ECFD for ; Wed, 21 Jan 2026 09:36:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768988217; cv=none; b=J8yf5pcVcBQLfU8R2w8V6cd+Z92XGCs1EZl39u2tAZXaLMqe9h81FTSRDgQaSdEz6f32FZrrEShQdMuiLJxjlsCo0ofRZvSQGXYTPQZViqtGgZa55OHZaONu6xpmzMK7uHEf/7/O5S8KMQPCQoQlsk71rZBXwM3n7YDDvvccs5E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768988217; c=relaxed/simple; bh=iqmFsw95eeMyB4kgugRjX3QYRWWCtwCFA+YNnFmxnAA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rXOoNqMPYuNLG7T1RYHmU94l9gOMTDfS7sT1cnX3+VYw7wfdOa3BAUJeklSHaX7qsYFrKuyNMNpmzgKtIw6Umi63wIRnlYL1Z1YwHRYRLhm4VEI3j6+JJWFtJdWusfB+gpkYLadwPV13ZuTbFJCyh8anqbhxjT066Vjg8A9xruc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=OtY1ZNLQ; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=FzR05uDB; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="OtY1ZNLQ"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="FzR05uDB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768988214; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oY0QgHfuK6okHlFI9jmjaQHqyNLbsKWPmz3mcrgnNlQ=; b=OtY1ZNLQBBEdU30oRTA3LwuHxDedgYfOqsOG7TPpIe7+KcAkoHFUoTdCcTO2hxTY/hOuMd iGNX4qInagzOn7o/pKsRf7v8zNgWiU+Hi7K2IsAOacNq5TY6lrkGFUuzxx/+n40/R/kBPB y7CRYOALXkjVM9F+hktQAQI91lPLBSc= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-333-kTrKa5A2MDerH6uHphwjlQ-1; Wed, 21 Jan 2026 04:36:53 -0500 X-MC-Unique: kTrKa5A2MDerH6uHphwjlQ-1 X-Mimecast-MFC-AGG-ID: kTrKa5A2MDerH6uHphwjlQ_1768988212 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-47d62cc05daso45337505e9.3 for ; Wed, 21 Jan 2026 01:36:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1768988212; x=1769593012; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=oY0QgHfuK6okHlFI9jmjaQHqyNLbsKWPmz3mcrgnNlQ=; b=FzR05uDBvIXq1WDhCXg78+pEa4s3hjNWJ2V+XKISAWwz2mczGgP/SRiSxQidAAlQgf urh3qqqL5BOYF1eVOOkTsmL5PoTdOWLTulsL/axJKiKO7xrthCgTUsVdYXMTiHlp7W+p tLDEyoiJwf3RzKru26+ezctULqO1JyGVNoeKnu+AE0BdCTmFzm3hB3qrZve9Q3qt+cIk 08KWjMxEUav5ARG7soUu6lsfNVF9guO4NeQuzKosmRTh5IQTcXzq4g7qJCZaSDyDOvwU UHX6P7roIm/R7FNHg2OfZW9Lpv8DAC6G3BJb/9E8we/zDwHjl98qAmikOj146+tFzcLB 1EDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768988212; x=1769593012; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=oY0QgHfuK6okHlFI9jmjaQHqyNLbsKWPmz3mcrgnNlQ=; b=j4+9wTrhKrmQi1bhVIzjU/m/pXwdAS3wQt2xaz7O0jEh+7uVdEYrwPi7dwferqA1A6 QR4FN/BUbrElCA/KHbD0n8Hp7sgHTu/beYLVvHLua8yOoAHA0r2kjmneV9zj0TRrhwTc spUe8g4VRsamapi61ne7r0Uuo59dHQFBAVuIiDUk6WsiQX0hXSqDh+ZWDNRzdVRwcZ28 iGZlb3x/8IIWSmI8GId5QVBoLgYkGs0yXUj19Vf8UEcJ4vZOJnTrEqNAnbSHtVEzu2uv MsPjBbFzksMAJrlrhEMIf/E/G2FLQcwAnzSFgKIlhDwFT91SgnJZZ2ScyuncajXdY8xs pTmg== X-Forwarded-Encrypted: i=1; AJvYcCWajUURLUJl2qdBs5pajv90PQyH8+rhl8ML2ClMkyr6qBqW7QSm0i533Re5S9f5YOjyP7m1hOicwxMKpfw=@vger.kernel.org X-Gm-Message-State: AOJu0YzOKG+v80RNDk6JfgM2jizq2A9FxpY9sU6IjWKRdHRr6dETMxg+ go34G0xcyrjjNHN6yMEqSdgvKvLzEEcahkV9x8we62ggrMvPdjYmd4Mcm9AKAlQNqCWRS6i8B2+ UWi0PlhO8sknwW3Y/DwA6drl0HBezSx2Hs+yk6RFh7w2taYWegddwGW9ukpbpxkWVrw== X-Gm-Gg: AZuq6aL3cY+doiGDul38UnU0AxT35Qt214IG3ir/VKTVk1/u+8hKU6K7l2MEBfTZqEC WHsVY/DwVaCySEGTOI9Zoo80xDwHZKgG2V4Hp9RycckfLfv/5vnU4ZVaCxoBaW6ekuHIjimRxR+ MhH8CWROWePT44xAnFRxlUtlGHbI/O/BRel3DuFJi9BRVUeBMovn494Kn56RHK4e1aSRK/FdZOy 9VKbV9yTY/WpgY1QiEFa0NmEwIOBg8oy4wJUUHm5V+uEFGwqLLuZeSsqu6HYwwYsUyXxUEcbHx/ XA66LnaELi3tYWvIsoBZEuoD8E7jyCl3yVJ397ZOz6PQoHTauKICssjw1SQeJoMtokqBO36BV// LTBjlxw/CsfIuqZ5FepXIC6S6paqjM+7v1slVvw4r8I7nScGW52fuemxr3sdi X-Received: by 2002:a05:600c:4e05:b0:45d:d97c:236c with SMTP id 5b1f17b1804b1-480416867d8mr47222045e9.21.1768988212138; Wed, 21 Jan 2026 01:36:52 -0800 (PST) X-Received: by 2002:a05:600c:4e05:b0:45d:d97c:236c with SMTP id 5b1f17b1804b1-480416867d8mr47221465e9.21.1768988211696; Wed, 21 Jan 2026 01:36:51 -0800 (PST) Received: from stex1.redhat.com (host-82-53-134-58.retail.telecomitalia.it. [82.53.134.58]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4358f12ee69sm11893828f8f.11.2026.01.21.01.36.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jan 2026 01:36:50 -0800 (PST) From: Stefano Garzarella To: netdev@vger.kernel.org Cc: Simon Horman , Eric Dumazet , "Michael S. Tsirkin" , Arseniy Krasnov , "David S. Miller" , Stefano Garzarella , virtualization@lists.linux.dev, Paolo Abeni , Jakub Kicinski , Stefan Hajnoczi , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Claudio Imbrenda , Jason Wang , Xuan Zhuo , =?UTF-8?q?Eugenio=20P=C3=A9rez?= , Asias He , Melbin K Mathew Subject: [PATCH net v6 4/4] vsock/test: add stream TX credit bounds test Date: Wed, 21 Jan 2026 10:36:28 +0100 Message-ID: <20260121093628.9941-5-sgarzare@redhat.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260121093628.9941-1-sgarzare@redhat.com> References: <20260121093628.9941-1-sgarzare@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Melbin K Mathew Add a regression test for the TX credit bounds fix. The test verifies that a sender with a small local buffer size cannot queue excessive data even when the peer advertises a large receive buffer. The client: - Sets a small buffer size (64 KiB) - Connects to server (which advertises 2 MiB buffer) - Sends in non-blocking mode until EAGAIN - Verifies total queued data is bounded This guards against the original vulnerability where a remote peer could cause unbounded kernel memory allocation by advertising a large buffer and reading slowly. Suggested-by: Stefano Garzarella Signed-off-by: Melbin K Mathew [Stefano: use sock_buf_size to check the bytes sent + small fixes] Signed-off-by: Stefano Garzarella Acked-by: Michael S. Tsirkin --- tools/testing/vsock/vsock_test.c | 101 +++++++++++++++++++++++++++++++ 1 file changed, 101 insertions(+) diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_t= est.c index 668fbe9eb3cc..5bd20ccd9335 100644 --- a/tools/testing/vsock/vsock_test.c +++ b/tools/testing/vsock/vsock_test.c @@ -347,6 +347,7 @@ static void test_stream_msg_peek_server(const struct te= st_opts *opts) } =20 #define SOCK_BUF_SIZE (2 * 1024 * 1024) +#define SOCK_BUF_SIZE_SMALL (64 * 1024) #define MAX_MSG_PAGES 4 =20 static void test_seqpacket_msg_bounds_client(const struct test_opts *opts) @@ -2230,6 +2231,101 @@ static void test_stream_accepted_setsockopt_server(= const struct test_opts *opts) close(fd); } =20 +static void test_stream_tx_credit_bounds_client(const struct test_opts *op= ts) +{ + unsigned long long sock_buf_size; + size_t total =3D 0; + char buf[4096]; + int fd; + + memset(buf, 'A', sizeof(buf)); + + fd =3D vsock_stream_connect(opts->peer_cid, opts->peer_port); + if (fd < 0) { + perror("connect"); + exit(EXIT_FAILURE); + } + + sock_buf_size =3D SOCK_BUF_SIZE_SMALL; + + setsockopt_ull_check(fd, AF_VSOCK, SO_VM_SOCKETS_BUFFER_MAX_SIZE, + sock_buf_size, + "setsockopt(SO_VM_SOCKETS_BUFFER_MAX_SIZE)"); + + setsockopt_ull_check(fd, AF_VSOCK, SO_VM_SOCKETS_BUFFER_SIZE, + sock_buf_size, + "setsockopt(SO_VM_SOCKETS_BUFFER_SIZE)"); + + if (fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) | O_NONBLOCK) < 0) { + perror("fcntl(F_SETFL)"); + exit(EXIT_FAILURE); + } + + control_expectln("SRVREADY"); + + for (;;) { + ssize_t sent =3D send(fd, buf, sizeof(buf), 0); + + if (sent =3D=3D 0) { + fprintf(stderr, "unexpected EOF while sending bytes\n"); + exit(EXIT_FAILURE); + } + + if (sent < 0) { + if (errno =3D=3D EINTR) + continue; + + if (errno =3D=3D EAGAIN || errno =3D=3D EWOULDBLOCK) + break; + + perror("send"); + exit(EXIT_FAILURE); + } + + total +=3D sent; + } + + control_writeln("CLIDONE"); + close(fd); + + /* We should not be able to send more bytes than the value set as + * local buffer size. + */ + if (total > sock_buf_size) { + fprintf(stderr, + "TX credit too large: queued %zu bytes (expected <=3D %llu)\n", + total, sock_buf_size); + exit(EXIT_FAILURE); + } +} + +static void test_stream_tx_credit_bounds_server(const struct test_opts *op= ts) +{ + unsigned long long sock_buf_size; + int fd; + + fd =3D vsock_stream_accept(VMADDR_CID_ANY, opts->peer_port, NULL); + if (fd < 0) { + perror("accept"); + exit(EXIT_FAILURE); + } + + sock_buf_size =3D SOCK_BUF_SIZE; + + setsockopt_ull_check(fd, AF_VSOCK, SO_VM_SOCKETS_BUFFER_MAX_SIZE, + sock_buf_size, + "setsockopt(SO_VM_SOCKETS_BUFFER_MAX_SIZE)"); + + setsockopt_ull_check(fd, AF_VSOCK, SO_VM_SOCKETS_BUFFER_SIZE, + sock_buf_size, + "setsockopt(SO_VM_SOCKETS_BUFFER_SIZE)"); + + control_writeln("SRVREADY"); + control_expectln("CLIDONE"); + + close(fd); +} + static struct test_case test_cases[] =3D { { .name =3D "SOCK_STREAM connection reset", @@ -2419,6 +2515,11 @@ static struct test_case test_cases[] =3D { .run_client =3D test_stream_msgzcopy_mangle_client, .run_server =3D test_stream_msgzcopy_mangle_server, }, + { + .name =3D "SOCK_STREAM TX credit bounds", + .run_client =3D test_stream_tx_credit_bounds_client, + .run_server =3D test_stream_tx_credit_bounds_server, + }, {}, }; =20 --=20 2.52.0