From nobody Sun Feb 8 05:35:15 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 0FDCB2F3624 for ; Fri, 16 Jan 2026 20:15:27 +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=1768594529; cv=none; b=MPmyjbILX18e9hf0YBK3k+H66Tz/1Hnb1OSHc6W1TEOECB4wKlM0MhHEMZtpjZCHaS9by/eQlVjoa+AYsII9ZXKZ9EEvv7SR7xTHjXIhT4CuCfq29oI68Mxze+wP4mG6eUPAPAOjC4Xn7i+/wETUqcli2DektD9s2JUWqS/gudc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768594529; c=relaxed/simple; bh=A/Z6X724OpOjH0JR1tZITqCXaxlg20lb95ngLUoUj2w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BE3V5QXOhT0fWX1tnShr+it1OZAKbH3hBJm+1sebQUzNb7ZnUaqVB2V6X8mb/LSpuO8wdO+uIpodkac94dwm4v8vubIE7NfWnLMQ3rNLE7zwakZGkK2Nq75td47lgTJNoazGuGi/jOcYbmEidGUWTBHqAWHLb3ZILtULnCggPkk= 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=BqIlU4e8; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=iu9kQ+IS; 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="BqIlU4e8"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="iu9kQ+IS" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768594527; 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=ArUbsQ+kNBjAUv+ApSXUG5Hd0kEcrS3qPgkd0OoiEwI=; b=BqIlU4e82bIfs0nNr/FeiPY7FvXZwJ8uf55JDQFM6xAKqp65X3cR3uJMOh5jBcH0Rliype Z1umZ0W060pizUpuFFEU76OhEwgauRkTQig9D52IWdupjymbeKJAwyvW4BKoPrRig0JQur F6yPvoPb9JHjuk62QPY0YCeM1VraKTs= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-426-1dsDDDI8Mbmj9ilnBYajLg-1; Fri, 16 Jan 2026 15:15:26 -0500 X-MC-Unique: 1dsDDDI8Mbmj9ilnBYajLg-1 X-Mimecast-MFC-AGG-ID: 1dsDDDI8Mbmj9ilnBYajLg_1768594525 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-47ed980309aso17488245e9.0 for ; Fri, 16 Jan 2026 12:15:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1768594525; x=1769199325; 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=ArUbsQ+kNBjAUv+ApSXUG5Hd0kEcrS3qPgkd0OoiEwI=; b=iu9kQ+ISQWJqsK5FtvBvvLkJHqRuxrbRBbDMK9HHXNpRKYVDbZqDkGT/pgvbQWDgp0 VtxfTWp5E3P5F+tGuFQMQIXUKWPx1SYqD2HH1FwNUmGYGfADPc/rzgPcxEGolpoq9DUD rOBrtOaRMDRt2Pm7igYdm2L92CAcg+A9Xij6Lu5e1GYjAsUJKnbSIiJ/mqSKv2F2cv4s xeUDIiWvgoc87MhPgd5WFaNrM2VcXgh/QiFi5+R4hbZXFKyPcOSh4b5MD+Qo+MkHGaxA qzEdokb5DfEzSg6x8D66yielR38HC05Kw6UevKqJmsR4K1Wr6em5Rv0IYBOxlxVxiRRD d7ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768594525; x=1769199325; 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=ArUbsQ+kNBjAUv+ApSXUG5Hd0kEcrS3qPgkd0OoiEwI=; b=L73xuy2NJbst2DM/G3SFhNNHh06rleZeGAJlWQLav6eZWQHshF7gguPggWLSpVdJS4 r5qwO8jPFIAW5mJiGx5BY/8FRyqRb/kWGbMO7xKWRnX2I43Hd+ajjW1yL7IE1utV5W1C Ca7GbzzWW3oxtNkQfDl5gk7VKGmiF0GKx6hn/dis2FXGd0JwAuOXTh5H4ENL3lwxsOda +LFPoU4VafjfQ7B+yC0ZCcyAiXuKo3r1kqEW9XwUmhzz5yDljFi53X6Z9HipcK7l4QbS 4/FTX7XLGh7QiFtAf99WMLVAu/YYrZJJSwN0OAh0U7lRv+IOzrmzdEw5pEG9T9U9yfOK x1yA== X-Forwarded-Encrypted: i=1; AJvYcCW7xc8WxgISYt/XxOFogKXmOkEtlloVEdEo9fzECj6E9v1udOWqELXR3JOlAIomuyJxMOfe/+c4AqwFxws=@vger.kernel.org X-Gm-Message-State: AOJu0Yx6Sv53LsRyIRrz8UDIt0DX14n3lW+3u5jkihRz1OBkQedPRfiX 7b/3J1mlurlOEQnaBxnzNb5oQpos2tOvIqwyZw5bGubho6eFVY2pOonug0T6BotZ6JkREBLFKGe S0RP9c7Yg1yifNxsGs6qmykX3ZoVI0PqNshnZfL7o1W9XakzVXtCWrDzQzS94dqu65Q== X-Gm-Gg: AY/fxX7OYPLJQwb0hEIQeLYQQyy7VPpBTLdEkroR1AHyuhjw9NCg6ya238Nngx0MBkJ FMLwtFpe1c6f95PZG/LjpOO/oDj6EU1CUPu0CRZlcHMDEQzC0oDkq+C72mD2BCarguRuCKvF4c0 bLtAktZRMo6hqqh5PLvdQ7/5tUy3qnRPLyilFpuVS/d/hfPNbZU67v1ZylWxxmbdvwZ11/nYd7g bW5CfS2xMJnJzyX2CLEdHX2Hfo3/+t24LjQKu0Vi2TU5qlzWLdFU5ET9piO4TaJAXSfh0ISDdJP FIosxLj79I9pyJrIZUYis4GLRH/H8AHJjJBRHxH65bF5vgM5R7+nXdQR+t/Km5ulA0qcFYuJ9ra cUR07PstJ6V/9IcdM/FfOCUDiQFyJ62CeQZKASDocaS0yv6iX+09fcHFVrv1+ X-Received: by 2002:a05:600c:1f86:b0:477:a289:d854 with SMTP id 5b1f17b1804b1-4801e53ca36mr57538805e9.5.1768594524938; Fri, 16 Jan 2026 12:15:24 -0800 (PST) X-Received: by 2002:a05:600c:1f86:b0:477:a289:d854 with SMTP id 5b1f17b1804b1-4801e53ca36mr57538465e9.5.1768594524424; Fri, 16 Jan 2026 12:15:24 -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-4801e879537sm57802005e9.5.2026.01.16.12.15.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Jan 2026 12:15:23 -0800 (PST) From: Stefano Garzarella To: netdev@vger.kernel.org Cc: virtualization@lists.linux.dev, "Michael S. Tsirkin" , =?UTF-8?q?Eugenio=20P=C3=A9rez?= , Stefan Hajnoczi , Paolo Abeni , kvm@vger.kernel.org, Eric Dumazet , linux-kernel@vger.kernel.org, Jason Wang , Claudio Imbrenda , Simon Horman , "David S. Miller" , Arseniy Krasnov , Asias He , Stefano Garzarella , Jakub Kicinski , Xuan Zhuo , Melbin K Mathew Subject: [PATCH RESEND net v5 1/4] vsock/virtio: fix potential underflow in virtio_transport_get_credit() Date: Fri, 16 Jan 2026 21:15:14 +0100 Message-ID: <20260116201517.273302-2-sgarzare@redhat.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260116201517.273302-1-sgarzare@redhat.com> References: <20260116201517.273302-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 --- 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 dcc8a1d5851e..2fe341be6ce2 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; @@ -1490,7 +1492,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 05:35:15 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 1C1DE2F3624 for ; Fri, 16 Jan 2026 20:15:33 +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=1768594535; cv=none; b=gkpaPdyt1103Rejry0XJ5FYEnREaPgYADsmHMxhmKv+/Eyl8WAz8NWOlcxP2VqxYSfkMeoYgWo76spw3a6m0UJB3PNGqhtTHE7FKnulj3xO7/XJtHNcpd4YcT63U+KySVFYoedNZkuvp15TDoDywUl0Ys0h6AnVzWD8eLQSPT3g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768594535; c=relaxed/simple; bh=JvMvAj7ZpINza73ylybZV6srp9RLkEGmGWUWUCTvQu4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QoUdgTlltnnMEylPFNMOLgwkRBIYAgG/fypcmRis2srpxgMVk3DelEfIKTQr/qTLOuQzMeS1XwfZXfcSa4qiiAfLB7SQpC8R7n798cl4JKvMwdqNhYhDW/tJGBAWXw4uh7i0/FYgKd9R9gt+UprNm2V640DaqcI/x5T3iYe2Gao= 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=T5Fg/iH8; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=s4drjzkS; 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="T5Fg/iH8"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="s4drjzkS" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768594533; 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=voXLQ/q07d6hv5Ud8qhwOuK2vYxSCpA8ze6BckDLUOE=; b=T5Fg/iH8XEvaTimViOWHu4w6D7Ae/DEt5qqUfRtZyHdJ1v0br0w+1y/gh36nzqmWP1eubD Ed+QOZ6dW1zeqqozgzPLerD+k7l67niy2HnvuDpqYOY/II/o/NRiBy1/yTecLiM63gyOJ6 nv9jT6Zlybp2YgRX+985oYjJgQaES/w= 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-155-xc91ImEQOWOHuIWoXACU6w-1; Fri, 16 Jan 2026 15:15:32 -0500 X-MC-Unique: xc91ImEQOWOHuIWoXACU6w-1 X-Mimecast-MFC-AGG-ID: xc91ImEQOWOHuIWoXACU6w_1768594531 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-42fd46385c0so1531668f8f.0 for ; Fri, 16 Jan 2026 12:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1768594531; x=1769199331; 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=voXLQ/q07d6hv5Ud8qhwOuK2vYxSCpA8ze6BckDLUOE=; b=s4drjzkSE7J8Ch70zdEa41Rb6nvttyuts1gOncRU5ubWNQGo1ZN5AdUwTBA7Od1Wsq CQcwnwkaoyVOp/11t121ssTNnVmRhK1x6+xfxaMzpjY6BBWUE1pMa7ssHwhqw5fcJJHS vSMkpIpNl9cd0TgSI4wa4Aet25nVRZH+ZFy46Kk86t4DaFME/8Ay9daZle4pvsBi+1AY 6byvPdkO9ua8aoe7vUflNtvWFb1e7YIdpCxtCQBjw0yR6cZ8rvptc5UAXGilss/31VGn hqCsRKClvb+itmKlRTt3T77bGh1eHu8AVihLEppmm9jf1tRgnYIrLnFck0sB1ZztBN39 URzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768594531; x=1769199331; 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=voXLQ/q07d6hv5Ud8qhwOuK2vYxSCpA8ze6BckDLUOE=; b=UMQ0hV5MsioJiA9EouT4Zjm5CCR9+v0UwGEI/HY62EVMeFnrJzBl9/7V+JNP0gGut/ mwk7kD+zavUdW7LuRf83kuo3sz238ImwKqG70c9MDvl+muaAZQuhqV+HydeBOeydhvnH 9pp8J5/n81R3zhMRQH/YRweBKYpCpWYgfmxWmvdicq4RAFZmlKGahFIm7kwZofqZr/f2 xSwq1+CeSG/HuRD5gD0bAQvq4D0/GW3EBbVcxH+xpGX6y6gn+kuAzsFBeJN+OG7GOOzg B6+KE/cbfTR7U/egkl6sbXROcyZ6VdJ2MofGlXSJ1XkM/zRr99f2t7d3sMcK4rxSHcnG CaVQ== X-Forwarded-Encrypted: i=1; AJvYcCVyOjQmkTuqdvuOO1z3qKVApAgZ7RUtGTWMqbf47O2e/n2u4+bDk+3X4eccdNilAsSTBbs6JJRpzGgBXaY=@vger.kernel.org X-Gm-Message-State: AOJu0YyF8/AohCsNB9oi/UU1pUccpVvEK53DdxeyRPd5Gah4eGzXVSIu K6NL3bLc8fQd4RFIQ+G4n0CU/n5xQdSQhCNZ8MPlxcruPuxl9g0cs3AW/ZO64M64SXAknl2R2av aIXoJojusPtdlBTZ3wSrpryBwaEsd08WUJzID2UMb1YX8hU7LYCN46uYd2FooQ7iMkw== X-Gm-Gg: AY/fxX4nJU750KUl9dtRCOhmaYlCOFeVYCHzTb/+IbPSd/wEaWYuMRdNrU+7qtt5Uza hRjGXegSKOW+GpD0IsA9pdDkEoLx2SSGVc0Oxq6WD//vXb4thY+D7+uEVeK6k9dqYahl8/CbfF4 bsF1xJ21s8Ua33L4H52FuqboGval2vx0IeLxdu/XrtDbNyoQysEBwposMd9mwqSkoEMJgrTcgXr i4vxpll8PwsX4SWlF44eCtyNm4AK7FsqSHX11VNR2eY1kpJO2k6iD6F0R/jziMYfEwjMqxOJwlU jhKLeCoaldbp7Dg1lcngEXZshTvgNanvqkzHehIBuN1k1zl1QcV2Iv3lrAXnXmV2ZIF9hAzu+tH 2C8Kahd2APN393Q5ePUnKmBXAqyhby0pyMw4pjY+gsTEGoKSKiiZBd7xIcauW X-Received: by 2002:a05:6000:238a:b0:432:c07a:ee62 with SMTP id ffacd0b85a97d-43569bd48a4mr5632688f8f.62.1768594530765; Fri, 16 Jan 2026 12:15:30 -0800 (PST) X-Received: by 2002:a05:6000:238a:b0:432:c07a:ee62 with SMTP id ffacd0b85a97d-43569bd48a4mr5632658f8f.62.1768594530330; Fri, 16 Jan 2026 12:15:30 -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-4356992681esm7109861f8f.11.2026.01.16.12.15.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Jan 2026 12:15:28 -0800 (PST) From: Stefano Garzarella To: netdev@vger.kernel.org Cc: virtualization@lists.linux.dev, "Michael S. Tsirkin" , =?UTF-8?q?Eugenio=20P=C3=A9rez?= , Stefan Hajnoczi , Paolo Abeni , kvm@vger.kernel.org, Eric Dumazet , linux-kernel@vger.kernel.org, Jason Wang , Claudio Imbrenda , Simon Horman , "David S. Miller" , Arseniy Krasnov , Asias He , Stefano Garzarella , Jakub Kicinski , Xuan Zhuo Subject: [PATCH RESEND net v5 2/4] vsock/test: fix seqpacket message bounds test Date: Fri, 16 Jan 2026 21:15:15 +0100 Message-ID: <20260116201517.273302-3-sgarzare@redhat.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260116201517.273302-1-sgarzare@redhat.com> References: <20260116201517.273302-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 --- 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 bbe3723babdc..ad1eea0f5ab8 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 05:35:15 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 C79293A35CA for ; Fri, 16 Jan 2026 20:15:38 +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=1768594540; cv=none; b=JVZFrSKsPYxbldA+5VZVMdlbno0mOicObX9Ghuv3avp1WcUWd6U/HpYTqHYQiRUlp4FOj7/tFyJ8PE8PSbteDZy30xYacDnpdvRB76qEfdipNK28IXsb2IMrDUpZrFwwCXGUncNwOMmtf6DhDVvfEWA80GTXiDTBbkxOqtPreIs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768594540; c=relaxed/simple; bh=vfLaZ/x6PhPiKKL/eiQKsaUIp8fH+OSFlnq0nAGw7+Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eQ2D2wHkO+zPTYxSfos57/+qabVJLFn9M28ikOcLo7LI6Uqg5DCb71PiMJWIPX6aeFzZ62hNsMEjoj+kquTKtWWCXw2Wor5tcGF2iJsxox+V6xrsQIOgwp00x+AM4o7+ZALXRYGdfvhY/Pci1Lj4/M3mMZx5zUbgKPnXDX1LXX0= 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=SuRlMT4C; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=MX0+RiMV; 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="SuRlMT4C"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="MX0+RiMV" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768594538; 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=JOY0EgIBRqk7jAnNyMBWfVkbAAKnvpv7/putmSk3IKk=; b=SuRlMT4CnzdsGLZ6uu2Y0Pko+i+p76p6Ct8xelVLk39Ly8bfR4SmFuzJyPJthXZNJb4nli nZjBVWchb2kH/v3QF4eamgmUIeN79aIs34f3iZRSUJotuGuYZCWja489dbBwoQbU7N3F1x UdryyhfH/y3lurELbZO3xIKvGJ081mE= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-486-1hb-hcpCPoOzOlZKKYMOlw-1; Fri, 16 Jan 2026 15:15:36 -0500 X-MC-Unique: 1hb-hcpCPoOzOlZKKYMOlw-1 X-Mimecast-MFC-AGG-ID: 1hb-hcpCPoOzOlZKKYMOlw_1768594536 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-4801bceb317so23574125e9.1 for ; Fri, 16 Jan 2026 12:15:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1768594535; x=1769199335; 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=JOY0EgIBRqk7jAnNyMBWfVkbAAKnvpv7/putmSk3IKk=; b=MX0+RiMVWg27Bgm69M7zcZdiqUI345cUEZpynDYy48eN8FCFeuEqvuR4zez0LPEbZc KV3wfa/mgdJRBU4cpqJzFfEc94teWpTEF0xOpgv5dQiaSnf3E3H8BX3CHNJMtw0WGAIQ uAL2VW097WD9vP5g4McGmoVR9YjAM8aUp9VtMbjnibtrUxKjmThENZAncB9XvX1+Lup/ ZxpU2MKyjRVh60KJYvvFLSSRhCFqWB52VHrpFPcFpytDCdEnS8cBQhyRN+RTjqtCN0Xm SYeamlds4eDHDgVp/sHCl23c6GoL385BbortQhFmNYUWMdtyEvS71dQE3EO7+cRokP11 CBvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768594535; x=1769199335; 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=JOY0EgIBRqk7jAnNyMBWfVkbAAKnvpv7/putmSk3IKk=; b=XTOxsJ65LQBc1og3nmbTm2Dv+z/KwXTks58IBQ/fcGRQdEKWkXgKDRe19xkT5/t+cU eQ6gm6gt+hCF848wiRQXJwOshqxP/Kx6O5gIZezMFdwwhMfdpbfSRQpO86IJPXScJnl5 xplqEpiVXcF9eUapm5narvlkCiinuna6PEazR2zKNNg0ro6Mvx7g/os4LMj+RUiPhbuc ykSTFdylSSkYiHfXoKgB/+lvtDBtq/zFvcmZJS1mYTLbE/i/LTNxPfp6yUJtZZvK5O4q cfRcte1TD6I8n/FSFTieVFNuNaA00H50a89jCV36/eeh8aNcagWL5CrtbnEwhd9GcpEj eY3g== X-Forwarded-Encrypted: i=1; AJvYcCVj2ZCTtDKCyEbC5uioTngnInyG50Z1xv7Kr1T423+Z+CSRmCGQHPblsQkeclgKBA7o3PZvzy7pv4vx+VE=@vger.kernel.org X-Gm-Message-State: AOJu0YzXiSOi+C4FP3/uEbsmgiJORn/0fZ8j4KPfs52RzCAgOoYZaG8n bkBqgBZnsBUS557zTpd3ip2QvZVgYobyMbyF4OcVQUHOocWja6y+rPn5P7r8GN7sCLGHntMQYki c2ObB+JQECbEaCnpG1vuditffZyYJaUHRv4WXc70SX2WOyn3tQuy524UpTickjlKojA== X-Gm-Gg: AY/fxX6lV+43vd3GXwYXxd1wxURuOniD4mNIAgW8Y18mXCvz1KEvo8FX/jonxILrbha codqdJHispZnIdcduJNPbU7Q4dCIi/z65mEqRIZ/hZKR9hSUZcvv8TD2OReqM1P8Uj3bUpthCGI 4/eNC31AhgMeqI6H3+kKFkGhdwJQbXuNmZ8mJoSlq/iC8itfbZNwGSZWllEgflrGlV4948Wj969 cBv7mDwYZ7WE0jcVjh9wNOgQeQkc7gDddIDny1Yxj63fewSO5wHWgAATDaoxFdg6zX6wr9T1nJs uSIcRWzJLSMWoSAmbcTeKDfqRJpw0paum2s17X5ZcgfE4npJVfJqdsme82CskW1bjrvUeFD2cp+ YWXYNBTDBvUc7G2/8wBD1gA34Wm9HSnBhbyxU2BNFsS/kzufG6YpCSeU+gEiX X-Received: by 2002:a05:600c:3495:b0:477:7975:30ea with SMTP id 5b1f17b1804b1-4801e343a9fmr50017465e9.29.1768594535499; Fri, 16 Jan 2026 12:15:35 -0800 (PST) X-Received: by 2002:a05:600c:3495:b0:477:7975:30ea with SMTP id 5b1f17b1804b1-4801e343a9fmr50017195e9.29.1768594535065; Fri, 16 Jan 2026 12:15:35 -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-4801fe65883sm22287425e9.15.2026.01.16.12.15.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Jan 2026 12:15:34 -0800 (PST) From: Stefano Garzarella To: netdev@vger.kernel.org Cc: virtualization@lists.linux.dev, "Michael S. Tsirkin" , =?UTF-8?q?Eugenio=20P=C3=A9rez?= , Stefan Hajnoczi , Paolo Abeni , kvm@vger.kernel.org, Eric Dumazet , linux-kernel@vger.kernel.org, Jason Wang , Claudio Imbrenda , Simon Horman , "David S. Miller" , Arseniy Krasnov , Asias He , Stefano Garzarella , Jakub Kicinski , Xuan Zhuo , Melbin K Mathew Subject: [PATCH RESEND net v5 3/4] vsock/virtio: cap TX credit to local buffer size Date: Fri, 16 Jan 2026 21:15:16 +0100 Message-ID: <20260116201517.273302-4-sgarzare@redhat.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260116201517.273302-1-sgarzare@redhat.com> References: <20260116201517.273302-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 --- 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 2fe341be6ce2..00f4cf86beac 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 05:35:15 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 99A2A3A7829 for ; Fri, 16 Jan 2026 20:15:44 +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=1768594546; cv=none; b=I33RBBG3PgczCgWclhjoX75dT8DwptmRmmOYmc+NsAijDR7J8e5kLTAkx1QobQb95FilnVp8iXXiOu+xaZpQiYCc600coUELYeyXRHVu8FOVOGh6xCzn7NrduaDxsu7vXO6NfmQ900DRzet73zGzzYopdw2Al6mFygQTlKIjd5I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768594546; c=relaxed/simple; bh=SoO7meievLXiEt+HOkmT+4mC7UVVo+dr6edO43jcmvA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dZ8GGG/C8qidG+aWBERiU1fnv0D+R6YLn9nCmLo975Nl5gZWeD139vKBzVyFYApku8FsDLBw2zO3gEVtjnFTPspEvM3iV6rs9Mphjv98TJg1a2/Fv9GYDEZs/2uABeYovbIcxnHXcBal20TVjBB1r8B2vKa2gpNJPKg4cS9LXbw= 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=F71rfD7h; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=gqnZ2UTG; 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="F71rfD7h"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="gqnZ2UTG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768594543; 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=IeRZ4N2lg6mPjyH8cqV8u8lDtZLcsrjhMu6bgHYQOx8=; b=F71rfD7hgMv4GDna79ZpAqr4433sX+/9wZQ9o7HSfbz+LUBZCBj5qXTz2wg6j68Yaeq6BJ P8IERdUVaGDOCGIVvWGH5RwX1zOwH7OxrCg8tiAAWnHQv8RIhhVcIIsyuqjzI69XUtPp3n ANKsWHTs8K5DfvL6WaRDbTh1gHGkfKw= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-257-eHEnGEDaO8qJiwogj-dr5w-1; Fri, 16 Jan 2026 15:15:41 -0500 X-MC-Unique: eHEnGEDaO8qJiwogj-dr5w-1 X-Mimecast-MFC-AGG-ID: eHEnGEDaO8qJiwogj-dr5w_1768594540 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-47ee3dd7fc8so20279295e9.3 for ; Fri, 16 Jan 2026 12:15:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1768594540; x=1769199340; 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=IeRZ4N2lg6mPjyH8cqV8u8lDtZLcsrjhMu6bgHYQOx8=; b=gqnZ2UTGU+LVgE1pbQQ8tbCY77BwwdKIH7BtjPhuCZ77qfHsrmY6V8rnWCwZw2/PWd irc/Y9bviFPlYyVLxs/Bu/JxeXNWepCkH5Ec8DMqKWuBK6xpa0Rnwg4d0a5kA4PTfbse O78AZvMRSHnzwQdZIT1ncguifp3+5lGyJWfQR9fu/l1F3w18BmsGztpghQ4BJxYAS4i7 Bjoa4ETxyQo43lU/U8Yz1oyfVJ2qFG9/ElQbMN6b6lsqXzQWF2W3VPXi7kA0NeCzaAxN KzzxHMnHWWpQSPVCBqCbSa78mHPiwVVjq+wUsWiSuMVUxYg+SRpRpH63cuNYSU8iLq7h hfhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768594540; x=1769199340; 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=IeRZ4N2lg6mPjyH8cqV8u8lDtZLcsrjhMu6bgHYQOx8=; b=T7TZcNu73/ftTncNec7aY9qUOcHE6VaO1PWVQ+X89spPq4fhdtzHMTqXAodWiG/jvm lLR4RBDYQnMSIZtIicUE6ftLTSnfEIYTvYhMKEH7V9TYRf6MkjsmVO5AWKjeAUbtvtYh Lv0YvPrzlIuvJr7k6chH+dIIFrvW5vrcnDj52IgxEtz99qeERQXmeu4nsaInCAAkUdA+ C1/o1gaAsqKaRBkbt8xgKJ5Jf+hJJlQoiKwjtpT2GML+g9eKOL+Fh40H1CP4GHQ4NNeF 5Na5jRivRmmJcXYsFxfRlfL8RSK82+UrZL/FVVCpxXy6WqFnHlCqk6pfcLZq/wQfFK1A p+Pw== X-Forwarded-Encrypted: i=1; AJvYcCU8EmwPibk5Hc8ItuWpvdRwqWMCPmIvlUSNT/i1vKyr2B+bLN6pYgmOeRJ19kIlNuX0sj+pOcMfZOuWNyc=@vger.kernel.org X-Gm-Message-State: AOJu0Yx/RaS1uRnMyZVjq6UZ2KrK7+70zDRt3oKSqCi+y684mCCuI9AY I7f7p6IIfJeNTIsRltxuTEKKRYKk2RrOsyRzann0bMl0jsMhoxRVvALBt3vXpUgpTCvIAksPnnT 79fnS5LVqQwkHwi/u6VwsHfkiME6kjMI5X4ZXnHJo7Yk2bbyy9ee4Qe6+8OpdeH27FQ== X-Gm-Gg: AY/fxX5/V/vMwDBwoh77k1HkA7CsPNmOubxNKqxGySLTmj8EQ/Y35OEHujecFqAMajO dNbVAIufARm73y8kA5Eo1vm1IXyBVN1CW8dDZ8m+JvtymWlZDuKlxuhuBoLCFeg8OVoesrMFo/x heRUA/My0MdCbLr2mfWe4OaciHtQUejHsvdpi6g/LaIag3HLPDnlJzn/PqiHvu23skY1VeTOt4s 8GKejg+ETRc1gpmiR4XM2EaJF0HiV84jUWgd0qba+edRCtTy++EoQ6Z8IiYjyR1/ob+9Cb+IAOf K6DyJZj5HR3/ncC4aK8GqvChVlc+X0C3uxghjXHcCB+DAZPVhbWZwpOFniPdHrJnsaS3eyM5ij8 ePXXDPBy2qSH9sab2xG4X7HIUctwJfkq1LrawJctR+aPNsDab1KsfqCDR4LBy X-Received: by 2002:a05:600c:4e93:b0:46e:4a13:e6c6 with SMTP id 5b1f17b1804b1-4801eb09274mr39557155e9.19.1768594540399; Fri, 16 Jan 2026 12:15:40 -0800 (PST) X-Received: by 2002:a05:600c:4e93:b0:46e:4a13:e6c6 with SMTP id 5b1f17b1804b1-4801eb09274mr39556825e9.19.1768594539909; Fri, 16 Jan 2026 12:15:39 -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-4801ea09747sm24213175e9.7.2026.01.16.12.15.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Jan 2026 12:15:38 -0800 (PST) From: Stefano Garzarella To: netdev@vger.kernel.org Cc: virtualization@lists.linux.dev, "Michael S. Tsirkin" , =?UTF-8?q?Eugenio=20P=C3=A9rez?= , Stefan Hajnoczi , Paolo Abeni , kvm@vger.kernel.org, Eric Dumazet , linux-kernel@vger.kernel.org, Jason Wang , Claudio Imbrenda , Simon Horman , "David S. Miller" , Arseniy Krasnov , Asias He , Stefano Garzarella , Jakub Kicinski , Xuan Zhuo , Melbin K Mathew Subject: [PATCH RESEND net v5 4/4] vsock/test: add stream TX credit bounds test Date: Fri, 16 Jan 2026 21:15:17 +0100 Message-ID: <20260116201517.273302-5-sgarzare@redhat.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260116201517.273302-1-sgarzare@redhat.com> References: <20260116201517.273302-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 --- 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 ad1eea0f5ab8..6933f986ef2a 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", @@ -2414,6 +2510,11 @@ static struct test_case test_cases[] =3D { .run_client =3D test_stream_accepted_setsockopt_client, .run_server =3D test_stream_accepted_setsockopt_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