> defined. I'm sure there is a good reason ;) > > Yes, I stumbled across that yesterday evening as well. I think its only > purpose is that it wants to be deleted :). I just didn't do it yet since I > don't want to see a merge conflict with this patch. > > I also need to check if the only usage of flush_tlb_page(), which is also a > no-op for s390, in mm/memory.c is not indicating a problem too. > > > > Changing active entries without the detour over an invalid entry or using > > > proper instructions like crdte or cspg is not allowed on s390. This was solved > > > for other parts that change active entries of the kernel mapping in an > > > architecture compliant way for s390 (see arch/s390/mm/pageattr.c). > > > > Good point. I recall ARM64 has similar break-before-make requirements > > because they cannot tolerate two different TLB entries (small vs. large) for > > the same virtual address. > > > > And if I rememebr correctly, that's the reason why arm64 does not enable > > ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP just yet. > > Ok, let's wait for Gerald. Maybe there is a non-obvious reason why this works > anyway. No, using pmd_populate_kernel() on an active/valid PMD in vmemmap_split_pmd() should violate the architecture, as you described. So this would not work with current code, and also should not have worked when I did the change, or only by chance. Therefore, we should disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP again, for now. Doing it right would most likely require common code changes and CRDTE / CSPG usage on s390. Not sure if this feature is really worth the hassle, reading all the drawbacks that I mentioned in my commit 00a34d5a99c0 ("s390: select ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP"). From - Thu Oct 30 14:49:54 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id aKLGBgx7A2nVvRIAYBR5ng (envelope-from ) for ; Thu, 30 Oct 2025 14:49:48 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Thu, 30 Oct 2025 14:49:48 +0000 Received: from am.mirrors.kernel.org ([147.75.80.249]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vETyF-000000075ze-3600 for hi@josie.lol; Thu, 30 Oct 2025 14:49:48 +0000 Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 7CCD2189E828 for ; Thu, 30 Oct 2025 14:45:25 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2BE67275AF5; Thu, 30 Oct 2025 14:44:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Qf7svA81" X-Original-To: stable@vger.kernel.org Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) (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 7F80A278753 for ; Thu, 30 Oct 2025 14:44:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761835491; cv=none; b=VPXCQU6ivgxg1h//glhJNUldqLEXGtUuOrnIHMQWNZE4sYA4DqtAic02ii56RS8LIRpCJ+LsRjIQMi53wkTU07VXW4JWt2rDnQMjC/f1S5Nwa7qyowB2CP4JYfcPHvX2oo+6WOhOEX4d4Pr4GZHQWW+iAve52veZGU+jBtB6QEo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761835491; c=relaxed/simple; bh=gG6Rxpv+5xwuYbGpv4ZcUhGKoTxFro2YHfn3sG0/O64=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=gIHptaWnt5cjIamwm/VfXc1lKco2vCmevYi4Xnau5a62VhHb4/HIUf6/lIPNy1W62ePTOWa8qFNkNMJDd/H33EjurEoK6BkajveeVhCZk9kwkqHdhe4iyYSlimfZ4ICj7hMm4nM1g6fvmdEloA8yU7DENAHI2WxQc0Bff6BA95E= 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=Qf7svA81; arc=none smtp.client-ip=209.85.214.180 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 Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-292322d10feso10541875ad.0 for ; Thu, 30 Oct 2025 07:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761835489; x=1762440289; 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=8i0KSYhBekRhZe3f+zVYiMKfUdeY1w53Ec33PFErQRM=; b=Qf7svA81zLPS7Jgqp38A8OMu2G0BSDFtQzbsnBoOeD2ObEGs1xD7+KI15v2TA/8cCm LXH5UurH5x0l44hLTK972xKIVAiWoFyBo5JMAl3xCESXpcezRSvbHgHR3iFJHxJmLzEy 6XMgzqU3JDOWJiAVyr+DNvUvfpdCpRwvUx+gWhGaG1EqAVgR0jglWx4qJnUQ5P4nctRO D1/Mwc84QjL+psDRRLKQThFp8UqQ5n/f+zR4op5Jl/nW00eeTw4zNwXnWx0Q+TuwXv8a tKVnK1yLWOeU3K72tFwzqWHkdmyrrwYMs9oREKsZWtpy/xQzBdK/9aUnfLdlOnMdyyV3 E5nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761835489; x=1762440289; 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=8i0KSYhBekRhZe3f+zVYiMKfUdeY1w53Ec33PFErQRM=; b=LABNgiUhVtmubLvOwtLFz1py7O7fl8WjZPzhzH7gm+L3uWuD1K6Yczy6WZwoFqeHLh 3MovZtlXFTfsMoE9qySdULmQHvwfKM5Kce0VwbYIDO7Ljpol/fEBxzEV5EMevysNX2T3 VMiM/Wzd56yNUgI+uMxCl+wIvWfNC6UyKWE7glaTZIiHf2wjxlwLnDLd2AOX+uJZWMHm +L7nk+gvfjA1lkunFIATy/vrm4whgPPbkuqh6DwIUBTbyIPxlW23SeOSw9TBnYSOeX9z uHZzMuwuWNVYFqm4cwroPO1rnoC3vwOcthW+nL3NEtBtG/1LkrdaL2V0q9WfKj07ViBE n1QQ== X-Forwarded-Encrypted: i=1; AJvYcCWVZvyoewAxYovjTRaTfR7Lv6uaeNxUhUziMAEiE45yt9aCS4Dvs56hT2Q2bfMQ2EYnkmapSXc=@vger.kernel.org X-Gm-Message-State: AOJu0Yx1Lum/mWyVPcZ+q3Fhs5IGwXOmviJFSmbo4shI5+ZDOTqYhFDS ZQabtpW7UAb1guiphE1lD8NQkZpWbH6pmyBgs40B1a8t6kXPjpsgucHk X-Gm-Gg: ASbGncuetHy7Vy8DJrAGOuI4+35ITTr5EnTyofUm3njzva8PVFLm4WHPPQfmVXZcriM lnOmlzN7ErfjCxtuZRfrOBEFAD4wb9ykkr+8f1rfSY3ojVnm2gLE0QnJ3wcFVOZyzdcXl3jwqq3 ihXX67y+xBpzXi2FDTCjYCgdY5FSywagsDbrHaisQmfIOGrLBG2ru1rsDMAm5WdYJczvhOGP1cR MPMo/iqhtZSWxzv6u2I4HH1bX7RemdaKDhTB/Eb7VLeUbfNLG2UGsyxrYxkVrF8nSeAfSOKhT5t 0BUDnVTKJTMeOk3XOwREk5JNm9XVWrewP0/lPNXKdU3btZkX4JsVLyeI56W9tS7+UF/eZNX/TWH PU6hehrC6MvdMkElsxXlaypnUlT8em2iSZDdamauCJ2rG1CCCBL4JakjRNT0m+W4QPawLBDkb83 pUgc+gnbiUqvPzMw== X-Google-Smtp-Source: AGHT+IFKdzh5PqIDW+UtJroUaPTVHXn8ZahZ8UZQ7XX0MsdR/YUksfFQ5V7KobNywlg1F1FyaLwELg== X-Received: by 2002:a17:903:247:b0:266:57f7:25f5 with SMTP id d9443c01a7336-294ed098015mr40411365ad.7.1761835488722; Thu, 30 Oct 2025 07:44:48 -0700 (PDT) Received: from minh.192.168.1.1 ([2001:ee0:4f4c:210:f227:4662:b8d4:840c]) by smtp.googlemail.com with ESMTPSA id d9443c01a7336-29498e41159sm188520295ad.91.2025.10.30.07.44.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Oct 2025 07:44:48 -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 v7] virtio-net: fix received length check in big packets Date: Thu, 30 Oct 2025 21:44:38 +0700 Message-ID: <20251030144438.7582-1-minhquangbui99@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-DKIM: signer='gmail.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [147.75.80.249 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider [minhquangbui99[at]gmail.com] 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 4 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 packets") Cc: stable@vger.kernel.org Signed-off-by: Bui Quang Minh --- Changes in v7: - Fix typos - Link to v6: https://lore.kernel.org/netdev/20251028143116.4532-1-minhquangbui99@gmail.com/ Changes in v6: - Fix the length check - Link to v5: https://lore.kernel.org/netdev/20251024150649.22906-1-minhquangbui99@gmail.com/ Changes in v5: - Move the length check to receive_big - Link to v4: https://lore.kernel.org/netdev/20251022160623.51191-1-minhquangbui99@gmail.com/ Changes in v4: - Remove unrelated changes, add more comments - Link to v3: https://lore.kernel.org/netdev/20251021154534.53045-1-minhquangbui99@gmail.com/ Changes in v3: - Convert BUG_ON to WARN_ON_ONCE - Link to v2: https://lore.kernel.org/netdev/20250708144206.95091-1-minhquangbui99@gmail.com/ Changes in v2: - Remove incorrect give_pages call - Link to v1: https://lore.kernel.org/netdev/20250706141150.25344-1-minhquangbui99@gmail.com/ --- drivers/net/virtio_net.c | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index a757cbcab87f..421b9aa190a0 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -910,17 +910,6 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi, goto ok; } - /* - * Verify that we can indeed put this data into a skb. - * 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. - */ - if (unlikely(len > MAX_SKB_FRAGS * PAGE_SIZE)) { - net_dbg_ratelimited("%s: too much data\n", skb->dev->name); - dev_kfree_skb(skb); - return NULL; - } BUG_ON(offset >= PAGE_SIZE); while (len) { unsigned int frag_size = min((unsigned)PAGE_SIZE - offset, len); @@ -2107,9 +2096,19 @@ static struct sk_buff *receive_big(struct net_device *dev, struct virtnet_rq_stats *stats) { struct page *page = buf; - struct sk_buff *skb = - page_to_skb(vi, rq, page, 0, len, PAGE_SIZE, 0); + struct sk_buff *skb; + + /* Make sure that len does not exceed the size allocated in + * add_recvbuf_big. + */ + if (unlikely(len > (vi->big_packets_num_skbfrags + 1) * PAGE_SIZE)) { + pr_debug("%s: rx error: len %u exceeds allocated size %lu\n", + dev->name, len, + (vi->big_packets_num_skbfrags + 1) * PAGE_SIZE); + goto err; + } + skb = page_to_skb(vi, rq, page, 0, len, PAGE_SIZE, 0); u64_stats_add(&stats->bytes, len - vi->hdr_len); if (unlikely(!skb)) goto err; -- 2.43.0 From - Fri Oct 31 04:18:05 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id MHduOtozBGn/4jIAYBR5ng (envelope-from ) for ; Fri, 31 Oct 2025 03:58:18 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Fri, 31 Oct 2025 03:58:19 +0000 Received: from dfw.mirrors.kernel.org ([142.0.200.124]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vEgHK-0000000E20u-2dIy for hi@josie.lol; Fri, 31 Oct 2025 03:58:18 +0000 Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.mirrors.kernel.org (Postfix) with ESMTPS id 6CA964E3068 for ; Fri, 31 Oct 2025 03:58:17 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 193F6288531; Fri, 31 Oct 2025 03:58:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="CVw/3pel" X-Original-To: stable@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 D86DA2874FE; Fri, 31 Oct 2025 03:58:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761883095; cv=none; b=ssbxL1vPZqUVGC1ufmZbSrWkMBmNGmTjmiRf3It3me+zrOR+R0MV1cNhngcabKTL3UCL9CpznfiydbDMck