From nobody Sat Feb 7 05:01:13 2026 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AE03F35504F for ; Wed, 22 Oct 2025 16:08:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.46 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761149287; cv=none; b=pZlCK1q9ZnWtMH56zYpLPOZo9rcSGLwr8TBdFPVOpgXzGUTMzXkE1Of0lB9w26dmWA9mCZrYVMAFaSc5yRBds5zHrM7T+y1sE/aK7G72XBP8q56Xht0fOIdJ06JTZ+jOLOXgJ9Pq7IiiqX8HJFMTLSYVTERrsEOuoHTDzABcsQU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761149287; c=relaxed/simple; bh=auzHCSUbL/L9ko4QwDjdjbZQ98SIJfRrjs+q/xktilk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=WGzyot5pLhruFPxXRxTxJxyrCvubLxtioLyQHzBlxS3nq3+X8vMjrX5WzQDWDFeTrGi6Ta+SlpZWzhgvrE1ZK7G9Rdh+Ism0QAgA+uSupHOt5L2W/281YhPf112VG7/QFzJJqCFf7xhzI0R6KRJp+WzGQ3euctxQR6F37/cGAcg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=GNGbQ043; arc=none smtp.client-ip=209.85.216.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="GNGbQ043" Received: by mail-pj1-f46.google.com with SMTP id 98e67ed59e1d1-33ba37b3ff7so1314932a91.1 for ; Wed, 22 Oct 2025 09:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761149285; x=1761754085; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=n9ABbt3qgyLh4i74MVszWBEA6Z+Ea2lJZRM4Xy5gRb4=; b=GNGbQ043z3QPjKquCcurU5NH9CGwYuQKLTv5JKeu3s7xvdARXpIwxOkg7ZxLPd/cxy K+8c+T9s5eDYPQbMyiAaQlBUKO8hkJETqZ3u6n2ef+pL5KKpY5xL/xm+v2+Rdto2M9SS FnAnTZunby6Z81hOAf2tHWBzpXisMrybhYFYVtNW1ysiRl3UUNSiamhrlLlp4jZwDaeS I+dq/2cvrc06OLu/hDkmcO2oCmBKN46Tnn/Qu3iwDMfuZRGWMPrESVA4EcuiGbxhkc7o cwXOZ9/T7d+odgrTbYx3+lnnumTpOr3Q7HQyfYFF0yI5gYZX/TMNs2TwP88JbLC6zqRO b7pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761149285; x=1761754085; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=n9ABbt3qgyLh4i74MVszWBEA6Z+Ea2lJZRM4Xy5gRb4=; b=PGmy0vpnE0vuaKYVKLaztIeZOHfkaHGCN23Y40pgme4H+jAwZw8bTmeNAlHF7h6kOc EolHoDHbXKCSzr7c3aa3XKbEio/nF343mKM9BY0J3xdYwPGxv8PTdUiohzAc2RyV2lYI l1kH0mrLOhcKL2+CvMbeaE/alSKulQHB2vYrMxKGCT7kDL5NeiVWp5m9PH5QVw0vRYZ9 ROxJbwatMvdtnPmYz+E6tQdCk/AohE8xKrKm+uPT4YHcpR6PApQrcTnV75E4CKIXArAo POUxZrzj/M8Xnh4axtWD/xmgFYU6St+dq5NfN39hqlrcFjc/8tDuAMaS/NIemWPsvk7l IrIQ== X-Forwarded-Encrypted: i=1; AJvYcCUKuZdQfXR//ifUPSK/Xc5svJ4NiPkwQq/NeLND38fwRByAxYYqx8i9xBmRtehtuMs0AfvO8RMCoYsWfKo=@vger.kernel.org X-Gm-Message-State: AOJu0YwNtCSdnw8ZPV28ElJWiTT/1F6csFbUGAMJ7GeS8/v0uZHlbe28 9Mfugc6erQ0ZlRTUqF4T5iG2BSTgYCLvyymgus5TqgGMST1/mJfA/BVC X-Gm-Gg: ASbGnctJmVaGvOn5SO6vgDHh0tcPywwrjGR2CohDg7AekYLNLmkITk2bEA9Y8ks/yrb Ia0BaeNKfGSyivgSazFipmCOpB4fwpgvBm/y57KF9vdT90FjW0jjzsdVZ9UP6TRhzsfX9DCPvTe 6Jw5JgfVZiB5XXgUdfHdXam9QR4ydJYSw5s94gTzYOHmy1Rtg1VthaOMaGuo5livpzfg241HSTb RnRiiMHqtJ8mlF/4farR+VCQ/8cD6y19Q79JZMje1dhacc0OilWqUrZsEeiNBrvF8K4QoE8CY0g uSCrc22Ehil7O4jiWlFAdXrjuQdkowKnErT/7AA39uhAGSVtvCGeQbNWLPp/L2nwnLTmlv+Gh/T 3soNjRd8/z4MG+jTQrjMxZSvGJeW6OUpX6q0GhWZmafArzYO2DKigN8GSw4rHukxd3Fy/u4J4bZ gFujOQsHUjztEdgakI1FzS X-Google-Smtp-Source: AGHT+IFKQtMp6Ai1uuAm7SgpDta9tGj5AFau6iGF+3bo3T12AjcV7wXz2cyGdxVGwafExfKv/O8axA== X-Received: by 2002:a17:90b:3c09:b0:32b:d8a9:8725 with SMTP id 98e67ed59e1d1-33e91ba3198mr2672703a91.18.1761149284702; Wed, 22 Oct 2025 09:08:04 -0700 (PDT) Received: from minh.192.168.1.1 ([2001:ee0:4f4c:210:1e3:b1:dcbf:ab83]) by smtp.googlemail.com with ESMTPSA id 98e67ed59e1d1-33e2090eff6sm1771750a91.2.2025.10.22.09.07.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Oct 2025 09:08:04 -0700 (PDT) From: Bui Quang Minh To: netdev@vger.kernel.org Cc: "Michael S. Tsirkin" , Jason Wang , Xuan Zhuo , =?UTF-8?q?Eugenio=20P=C3=A9rez?= , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Gavin Li , Gavi Teitz , Parav Pandit , virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, Bui Quang Minh , stable@vger.kernel.org Subject: [PATCH net v4] virtio-net: fix received length check in big packets Date: Wed, 22 Oct 2025 23:06:23 +0700 Message-ID: <20251022160623.51191-1-minhquangbui99@gmail.com> X-Mailer: git-send-email 2.43.0 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" Since commit 4959aebba8c0 ("virtio-net: use mtu size as buffer length for big packets"), when guest gso is off, the allocated size for big packets is not MAX_SKB_FRAGS * PAGE_SIZE anymore but depends on negotiated MTU. The number of allocated frags for big packets is stored in vi->big_packets_num_skbfrags. Because the host announced buffer length can be malicious (e.g. the host vhost_net driver's get_rx_bufs is modified to announce incorrect length), we need a check in virtio_net receive path. Currently, the check is not adapted to the new change which can lead to NULL page pointer dereference in the below while loop when receiving length that is larger than the allocated one. This commit fixes the received length check corresponding to the new change. Fixes: 4959aebba8c0 ("virtio-net: use mtu size as buffer length for big pac= kets") Cc: stable@vger.kernel.org Signed-off-by: Bui Quang Minh Acked-by: Jason Wang --- Changes in v4: - Remove unrelated changes, add more comments Changes in v3: - Convert BUG_ON to WARN_ON_ONCE Changes in v2: - Remove incorrect give_pages call --- drivers/net/virtio_net.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index a757cbcab87f..0ffe78b3fd8d 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -852,7 +852,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info = *vi, { struct sk_buff *skb; struct virtio_net_common_hdr *hdr; - unsigned int copy, hdr_len, hdr_padded_len; + unsigned int copy, hdr_len, hdr_padded_len, max_remaining_len; struct page *page_to_free =3D NULL; int tailroom, shinfo_size; char *p, *hdr_p, *buf; @@ -915,13 +915,23 @@ static struct sk_buff *page_to_skb(struct virtnet_inf= o *vi, * This is here to handle cases when the device erroneously * tries to receive more than is possible. This is usually * the case of a broken device. + * + * The number of allocated pages for big packet is + * vi->big_packets_num_skbfrags + 1, the start of first page is + * for virtio header, the remaining is for data. We need to ensure + * the remaining len does not go out of the allocated pages. + * Please refer to add_recvbuf_big for more details on big packet + * buffer allocation. */ - if (unlikely(len > MAX_SKB_FRAGS * PAGE_SIZE)) { + BUG_ON(offset >=3D PAGE_SIZE); + max_remaining_len =3D (unsigned int)PAGE_SIZE - offset; + max_remaining_len +=3D vi->big_packets_num_skbfrags * PAGE_SIZE; + if (unlikely(len > max_remaining_len)) { net_dbg_ratelimited("%s: too much data\n", skb->dev->name); dev_kfree_skb(skb); return NULL; } - BUG_ON(offset >=3D PAGE_SIZE); + while (len) { unsigned int frag_size =3D min((unsigned)PAGE_SIZE - offset, len); skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, page, offset, --=20 2.43.0