From nobody Mon May 25 05:54:38 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 74FD43E4C79 for ; Mon, 18 May 2026 09:07:08 +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=1779095229; cv=none; b=LIvmhBPg2doRXp+oMytd6t0qH8Wl3UAC9urj/Jnpi65xlwSKlWLDJwaAM7SVkbySKYbYu6c69P+sZtDaeCpitkCM1bEZT6wMca82sh/Fz8ng4mvCD4wvFL4Y7xoJRnxB6XmvZaP/SRL5q3kunzLU5uCrcwRmP1m+UCmA0cHMicE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779095229; c=relaxed/simple; bh=uQ6Wln7pJey/LF1d0dz2kzM3P6XyAQup1rTFP8pIs04=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lQ00xqup/tOc+N3CgLUkFeG7Fz9xvuUha4MPaDGDnMK3MnTsYwKPbgJWMQmu8bz+27jV+g0g3nVPXLYm6x6YTFbF6kxfkZ3EgJvtkubfHCXD+f7AgfbxXGygTTqzUAuBfvzQEoiamNtNoZuwMHE7byPQ2UUlkFlQXLn6m4NY2rQ= 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=VO8tJG6S; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=S6888Ohs; 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="VO8tJG6S"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="S6888Ohs" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779095227; 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=200SzWxPjUpvXvgPwqt07Qg/dRT4TNSJWBHGA2MWMbU=; b=VO8tJG6SZAN85Fv2pDSxlTG8UL72wUsZ8VsqDIxgY8MajWoH+1r/lCQy787fX8H+Jl7uRa B4TxLdvqQTgoImVkR5uNsUKex9nuoJ9dy/0lJgvpSe7j4IshDNm/3yE6Ns1LfoOkDlaj7n mWAh57A5w5yx96NBkFQGOBKG2jI5Zm4= 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-477-5ASOkjHHPUu6ZkfWrJ1YlA-1; Mon, 18 May 2026 05:07:05 -0400 X-MC-Unique: 5ASOkjHHPUu6ZkfWrJ1YlA-1 X-Mimecast-MFC-AGG-ID: 5ASOkjHHPUu6ZkfWrJ1YlA_1779095224 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-48a589c7879so20696965e9.1 for ; Mon, 18 May 2026 02:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1779095224; x=1779700024; 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=200SzWxPjUpvXvgPwqt07Qg/dRT4TNSJWBHGA2MWMbU=; b=S6888OhsGUJrpUapZHoe8wg1D12MJ6Z1NYXzeXUUO8b0icS0Ieaf0khOTB42Ka6b64 rGzI5WyAHJusNVZMEDEv1Y1l68BFh5EgxaqFuAzM9w7W8rFk5p1qwoXk5tyTCnBF3Wtw Q9TU2ROluUhopKxci8X0cXmGif/+zMxqbWhHj+UgxjacCFQwr6iY8G7KrcVFr7mCGQmP 8cQqJvHMIEJxRN4JvZGZJIexyN9EbAF06C25NeRXa8++U08ipne/syIdg4VKuwfT2Kok B9qTVlXtqfxEq7qZvLRegwM9llVh7KQ759O/eIoMvuFWTySy+CfcBx/yRA0WNhQXZyRD Zp4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779095224; x=1779700024; 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=200SzWxPjUpvXvgPwqt07Qg/dRT4TNSJWBHGA2MWMbU=; b=lvhYfd/MFoCtTKA8MsNO6DbAkyIQF5xXuyunuPmVsHKo1xzJPbL8Dmk7TdzGA+w7+f fTzwbt4tHp7RItnKcLoYMeISIz/kRBJJCUEho9hjvwJoOVEGMebkMyMiqnSJvORShLSW H6Y8zI/0U/PNumoCdl/5TL8Qp2D8wF/1TgUNUSMfCq5gVApRWpKOB+PPRBfb71b2xVHN qYsAzIazDy60Tglinf3krUl3wwtjFCXyAj1zOrPb8q/O7jv8MvqO+ipHb7qPR3MEb3VB eyYcv8RejyJDu77ZNUMzQkom2pwo1nFmZa3CAHVXZEKzV3CWZ25ZlOMN0w0PQ4M8qZRE KkKg== X-Forwarded-Encrypted: i=1; AFNElJ9MpP7jEjHajeAz837aYTktJx57ZqBcfT99W6j6Y7BESGCJ4MvDt7SzEupMz28LiloHDIneksqumHjzJnI=@vger.kernel.org X-Gm-Message-State: AOJu0Yz9vTM/uxocHyAB4eX4yNcDgr7q3cXoXA28oXOXQ1eWY3G8rXzb b6TJ0SNZ0IOIp+EYIshJlr/krYSvSjV594PGkbqOCr/VkSglY+GZrFkifzYU/x88FkCoy8MHz/7 HwU7gqSN8e3da6fD2oF26RWNFCmRLGst+2g/TuCUkz0nnGV54wldeAqVIHrzcmcbMmQ== X-Gm-Gg: Acq92OF9pnEGM7RnqYKkeP1QflhHpCvGq+PVxyl7z28tBm5VkFdHC58LtDS8fiU6AMJ /2/EcgfnKjMeN7a2lB05NZwiuofg52vfxnXMQA5voneiAftD4mJlRjpFMFnats5rOXMgX6Wv2vd dlGveWEUr6+nKXfsmM9iGOhMa5aaCQ2GB8wzixotG69o43FkyrofHsjucomTfY4PN6ng4mg8BSd 3cN149mJfOqtPS0beLgdDzED4yDVs3JK07W41rlMB/vfWj7v17c2xfiHIeWmxoUTwmEOCBVhx6P g2+skm+JIsxKK4TKX9DEJTFIYiI0zj0WJppkYDnItZHTXQvNhxcK7T2mUPfZ8mHm0bBAQ24vyK3 Tv1h7hRabxDtL1Nqrcqfv6/koX+U07xcmQNiMPDTLvGdvxV3FqVxe6BqKElzs X-Received: by 2002:a05:600c:1515:b0:48f:fe2a:107a with SMTP id 5b1f17b1804b1-48ffe2a10b7mr66193275e9.3.1779095223694; Mon, 18 May 2026 02:07:03 -0700 (PDT) X-Received: by 2002:a05:600c:1515:b0:48f:fe2a:107a with SMTP id 5b1f17b1804b1-48ffe2a10b7mr66192625e9.3.1779095223029; Mon, 18 May 2026 02:07:03 -0700 (PDT) Received: from stex1 (host-87-16-204-231.retail.telecomitalia.it. [87.16.204.231]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48febe6b60csm105880345e9.6.2026.05.18.02.07.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2026 02:07:02 -0700 (PDT) From: Stefano Garzarella To: netdev@vger.kernel.org Cc: Simon Horman , Jakub Kicinski , "Michael S. Tsirkin" , Paolo Abeni , Jason Wang , Stefano Garzarella , "David S. Miller" , kvm@vger.kernel.org, Stefan Hajnoczi , linux-kernel@vger.kernel.org, Eric Dumazet , Xuan Zhuo , virtualization@lists.linux.dev, =?UTF-8?q?Eugenio=20P=C3=A9rez?= , stable@vger.kernel.org Subject: [PATCH net v4 1/2] vsock/virtio: reset connection on receiving queue overflow Date: Mon, 18 May 2026 11:06:55 +0200 Message-ID: <20260518090656.134588-2-sgarzare@redhat.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260518090656.134588-1-sgarzare@redhat.com> References: <20260518090656.134588-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 When there is no more space to queue an incoming packet, the packet is silently dropped. This causes data loss without any notification to either peer, since there is no retransmission. Under normal circumstances, this should never happen. However, it could happen if the other peer doesn't respect the credit, or if the skb overhead, which we recently began to take into account with commit 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue"), is too high. Fix this by resetting the connection and setting the local socket error to ENOBUFS when virtio_transport_recv_enqueue() can no longer queue a packet, so both peers are explicitly notified of the failure rather than silently losing data. Fixes: ae6fcfbf5f03 ("vsock/virtio: discard packets if credit is not respec= ted") Cc: stable@vger.kernel.org Signed-off-by: Stefano Garzarella --- net/vmw_vsock/virtio_transport_common.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio= _transport_common.c index 1e3409d28164..5028ff534888 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_common.c @@ -1335,7 +1335,7 @@ virtio_transport_recv_connecting(struct sock *sk, return err; } =20 -static void +static bool virtio_transport_recv_enqueue(struct vsock_sock *vsk, struct sk_buff *skb) { @@ -1350,10 +1350,8 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk, spin_lock_bh(&vvs->rx_lock); =20 can_enqueue =3D virtio_transport_inc_rx_pkt(vvs, len); - if (!can_enqueue) { - free_pkt =3D true; + if (!can_enqueue) goto out; - } =20 if (le32_to_cpu(hdr->flags) & VIRTIO_VSOCK_SEQ_EOM) vvs->msg_count++; @@ -1393,6 +1391,8 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk, spin_unlock_bh(&vvs->rx_lock); if (free_pkt) kfree_skb(skb); + + return can_enqueue; } =20 static int @@ -1405,7 +1405,17 @@ virtio_transport_recv_connected(struct sock *sk, =20 switch (le16_to_cpu(hdr->op)) { case VIRTIO_VSOCK_OP_RW: - virtio_transport_recv_enqueue(vsk, skb); + if (!virtio_transport_recv_enqueue(vsk, skb)) { + /* There is no more space to queue the packet, so let's + * close the connection; otherwise, we'll lose data. + */ + (void)virtio_transport_reset(vsk, skb); + virtio_transport_do_close(vsk, true); + sk->sk_err =3D ENOBUFS; + sk_error_report(sk); + vsock_remove_sock(vsk); + break; + } vsock_data_ready(sk); return err; case VIRTIO_VSOCK_OP_CREDIT_REQUEST: --=20 2.54.0 From nobody Mon May 25 05:54:38 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 219753E63BA for ; Mon, 18 May 2026 09:07:11 +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=1779095234; cv=none; b=WQn5396TJ+XonY6+qYFKFzpu2bP78pyHg89MPmScGtv395oaVIClzMPDMQjEUp24gcdPjyqoMdx3HYcC9zcHU/Yc32qSCKHzOwEaVSWR4Gl+lGR5baAjbc6rUy6HLg7243RjeuXOQJMzyLP6lR351bDVUaHmnOLUsCUEqUPGbWk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779095234; c=relaxed/simple; bh=eYAsyzlcZhIaTkBbynj1OR7+7bApP1e2I2Pa+c+c3J8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=B3fc6t/D4HO1KIyxZq/qvAQMH4RlOYlfXKCv4IJ8YkYdeXzJkN9MD/b4KXVFmTSF9a4drEQeIGzXZ3eilfS+zqGv/4uYSm/eVne9GZJ5Br2eegQuAxt5B55ZPnyOiu37cutEdBrZ/BC2vy6D6F/n0VLftKhdSIYdbzgVo0psN48= 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=cV0Mjq7h; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=q0WqA1yB; 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="cV0Mjq7h"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="q0WqA1yB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779095231; 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=dsBo8SZnL+tIoKyB10yuoDT3WWwlz7J8lfIk8OOzpIc=; b=cV0Mjq7h4udO/IE8ULNaDpfN78BaEqHzpoBJGvbUwQYt4qHmLqNy1R0XlV3MGp+juN48C5 w0b1YSlzAVdB5Yuw1oncQ4OSOAGnVar35K2HMegAvSfYUoFVfKiHhWreWJGXwjeOGo0YIi MS2GqlQpEmORBorrV8zxpvK3gB0+zro= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-540-nv6q_BJ5Ny6W--qeyA3DRQ-1; Mon, 18 May 2026 05:07:09 -0400 X-MC-Unique: nv6q_BJ5Ny6W--qeyA3DRQ-1 X-Mimecast-MFC-AGG-ID: nv6q_BJ5Ny6W--qeyA3DRQ_1779095228 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-44696b11265so3163517f8f.0 for ; Mon, 18 May 2026 02:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1779095228; x=1779700028; 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=dsBo8SZnL+tIoKyB10yuoDT3WWwlz7J8lfIk8OOzpIc=; b=q0WqA1yBuKqudkMDVa9gbdGVzMuIsrVVXNRSwdw3bjgtKnlxMLvJDWrMYDVPEUDhj9 0QvedwBtRKqNr2F1FrzlxHjJIDmlaHNTkjOmFKFwsewObfVeXX9z/j5l0LsA+LurGglO C+aHH7ig9mUcgvF37isjI/JUvEGBJHCyMacgjX7fVv3Cikju5hbhhdzNY9MJNsmfKCXC TvvuMtEd7rfvBcZdRbjvQDJrtxVYVcMnoW2RPb+r9/O/atMX0gSuu+aBKebuGAWQAb48 xlb6ZaThvvV5Fwn67avpYSW3LgKF2Uv/xlmpcz0ykEMEEAXQJOFlRd8ijkcQQGqcYFtc PEpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779095228; x=1779700028; 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=dsBo8SZnL+tIoKyB10yuoDT3WWwlz7J8lfIk8OOzpIc=; b=PY5e9ulUrytKq/rAlMFS0e23FXJ3F8XcMVDZWnODxVve8ZOOo3OqrvUfKbrmKcl79E RTFlCCHhR6Mmza6aqQpaQpghF8/Z1oyBNitQQ2F3l2vBTs6oT98nScwP1eG8Y9fOLGwh uFEzxqcjZ6C2y2w/SuPmKu8uFbedsbNt7GDgwIhmRdH1O1BHwc5o2j9aVG+UQX+7P9+w TYQg0wZNtxqgxYoAkCTnJDfqiZLrkHBhCgGgdSqlpEHZ/BW4FQ6vPTAEd4E5rJcEY8ND /dX9uhZJrGSGhwtRBC7ZdFs6X9CMrpnVgtcRc5D6mPVpFPVdKs93eYcFMBHzTsg6nsD9 cfJg== X-Forwarded-Encrypted: i=1; AFNElJ/ELDr+dVfsY3TtDIZNy6Dnwa/t5hNpRFCV4YvQWs0SwZXxYTDrO4l9ZHwCQBXAYXQg6fo9MCH4AnLWtoU=@vger.kernel.org X-Gm-Message-State: AOJu0Yw1NHLC6sFfqj7Z2mLws/xGGs/yDnSX8sNVSsyVCrcEshwYLMs3 hnC3CzWrCBBC/rNz7X6Cqczno7mMZITAH+kG9LuwIzREtAPLafIoDO0Ihz6mqgWQ5wq7FaJpsh1 /taAhNcdT1pLW0a0YrsVOxVJD+GGg34gLUFOnKo/73qdV3EN6F18UW4NzAnLcAUiUQA== X-Gm-Gg: Acq92OF2dfZKYRFopr4GfGDbrKM8bg72gz2AFFVp1kFBlsRUjtX5AJwIrCIG2lpJCzW D+9/98Udyj0q8yUkQziG0ikR+UpJgKX4FzVYm6HDZIWQO7r8KfSULyFRcSW8HH4hQCmKVgsVxtp 3OSO3nrSoxnA7hrsvuG0gaCzHK/5b9UqqHIqeA4zdG35s7to3/e/+BzT36bLYFuM/L+QJjX9wVi FVmjGuf/tJ7pLu8cfXZXxmIfHSQsXN7VpawyyJRac9cakjaNgFz6T6CvdfRgXqLgxfHt/8hsg3Y OJDNb+OS5/WRbEAyVrRlYf1RML0x1u+TaJ8GB7PZ+2PGOTYpiv8fdi7/h1N5ZSe34T4kmUsjUiy aVpdWGDPHKSm5N6R+8z8aoImS+lMWjIXC1X2xOawCJLVW9rwS14csXglLAZRChZZTiCDVd2g= X-Received: by 2002:adf:e681:0:b0:45e:633e:a7cc with SMTP id ffacd0b85a97d-45e633eb4e9mr14807932f8f.24.1779095228401; Mon, 18 May 2026 02:07:08 -0700 (PDT) X-Received: by 2002:adf:e681:0:b0:45e:633e:a7cc with SMTP id ffacd0b85a97d-45e633eb4e9mr14807870f8f.24.1779095227874; Mon, 18 May 2026 02:07:07 -0700 (PDT) Received: from stex1 (host-87-16-204-231.retail.telecomitalia.it. [87.16.204.231]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45d9e768072sm35104134f8f.5.2026.05.18.02.07.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2026 02:07:07 -0700 (PDT) From: Stefano Garzarella To: netdev@vger.kernel.org Cc: Simon Horman , Jakub Kicinski , "Michael S. Tsirkin" , Paolo Abeni , Jason Wang , Stefano Garzarella , "David S. Miller" , kvm@vger.kernel.org, Stefan Hajnoczi , linux-kernel@vger.kernel.org, Eric Dumazet , Xuan Zhuo , virtualization@lists.linux.dev, =?UTF-8?q?Eugenio=20P=C3=A9rez?= , stable@vger.kernel.org Subject: [PATCH net v4 2/2] vsock/virtio: fix skb overhead accounting to preserve full buf_alloc Date: Mon, 18 May 2026 11:06:56 +0200 Message-ID: <20260518090656.134588-3-sgarzare@redhat.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260518090656.134588-1-sgarzare@redhat.com> References: <20260518090656.134588-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 After commit 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue"), virtio_transport_inc_rx_pkt() subtracts per-skb overhead from buf_alloc when checking whether a new packet fits. This reduces the effective receive buffer below what the user configured via SO_VM_SOCKETS_BUFFER_SIZE, causing legitimate data packets to be silently dropped and applications that rely on the full buffer size to deadlock. Also, the reduced space is not communicated to the remote peer, so its credit calculation accounts more credit than the receiver will actually accept, causing data loss (there is no retransmission). With this approach we currently have failures in tools/testing/vsock/vsock_test.c. Test 18 sometimes fails, while test 22 always fails in this way: 18 - SOCK_STREAM MSG_ZEROCOPY...hash mismatch 22 - SOCK_STREAM virtio credit update + SO_RCVLOWAT...send failed: Resource temporarily unavailable Fix by allowing at most `buf_alloc * 2` as the total budget for payload plus skb overhead in virtio_transport_inc_rx_pkt(), similar to how SO_RCVBUF is doubled to reserve space for sk_buff metadata. This preserves the full buf_alloc for payload under normal operation, while still bounding the skb queue growth. With this patch, all tests in tools/testing/vsock/vsock_test.c are now passing again. Fixes: 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue") Cc: stable@vger.kernel.org Signed-off-by: Stefano Garzarella --- net/vmw_vsock/virtio_transport_common.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio= _transport_common.c index 5028ff534888..df3b418e0392 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_common.c @@ -419,7 +419,14 @@ static bool virtio_transport_inc_rx_pkt(struct virtio_= vsock_sock *vvs, { u64 skb_overhead =3D (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0= ); =20 - if (skb_overhead + vvs->buf_used + len > vvs->buf_alloc) + /* Allow at most buf_alloc * 2 total budget (payload + overhead), + * similar to how SO_RCVBUF is doubled to reserve space for sk_buff + * metadata. Check payload against buf_alloc to be sure the other + * peer is respecting the credit, and sk_buff overhead to bound + * queue growth. + */ + if ((u64)vvs->buf_used + len > vvs->buf_alloc || + skb_overhead > vvs->buf_alloc) return false; =20 vvs->rx_bytes +=3D len; --=20 2.54.0