Received: by 2002:ac2:464d:0:0:0:0:0 with SMTP id s13csp3681506lfo; Mon, 23 May 2022 11:15:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzV5ykrBu5t5/BEkIXygYiDvLWCmO0WsZ8AKTFBY6ooOZ5nGcQ9Y2i+fUGAkvXeqHAVrS1r X-Received: by 2002:a17:902:8f86:b0:162:22ff:496b with SMTP id z6-20020a1709028f8600b0016222ff496bmr6297808plo.105.1653329748597; Mon, 23 May 2022 11:15:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653329748; cv=none; d=google.com; s=arc-20160816; b=t6FhE6dxbnSNfu/ygOih3Vw/bWaVOXsV2kvaLDW3M3cz2IwRVl9d6hd7fvo2iPCFRn 9a0o2b9kSCGKngokzjhoA+deOyUX6TqK0G9mT2H53pnYumzkXbs+Ht6+THWR/Uzb7fQz faD44D5kF1rwbsGysuKdcHVO38mZ4VV3AfEra+JUc/bRNI+65Nn9bQXwHESkVDcfzvxF /MaUfHo6tyxprEiCaO35Y24xxnLw6SMUyWropSi4vaJXdJcccC2D9rEpJ6ObSNrpPZnT o+dBh75ok+IruiK4blYkxUXi/XT/QbYhOtJp7vrSfWaA3Xx+Hvwbb6GY3xII7mtsLWeh NaJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=9wnKXnxdZ5jT3mNbhcqJdmp8u9V/sfhhMJf6g7EtQA8=; b=k5uyjRZ5CRf5byeO4RStMSBZ9gAf5x38osAfqr9nj7xaTptfje9qFYOE4Fwyfdh0ZU mwQF+qqw2DYkNT6rp/xrCoTPAe0k8U5Vw3wOWsMSbY/3rb6p9OK/4qvD6zzviGhFw3EH Yf43GqnxuTn1AC1j2Q9U5MmunkkZHetLfH69vHjh2VA0xE/uU/bMzyAotEFRzql/ZN7O mIDLAaEZfzXpvTJSfFzOfs/os7EzVdSMuZQkMBiWJxrEBlIDQtDG8T1x7epKY4b98afH NSFJEhF++d+O876O9i72Z21CemoSkvKgqmm2b0MN3lGqmjr7j0rrU7e474RD7/AEXc5D CjXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=nSRRIbTE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id b2-20020a170902b60200b0016160b8d0e6si12235265pls.542.2022.05.23.11.15.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 May 2022 11:15:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=nSRRIbTE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 59A451611C2; Mon, 23 May 2022 11:14:06 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243101AbiEWSI4 (ORCPT + 99 others); Mon, 23 May 2022 14:08:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39388 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243568AbiEWRiS (ORCPT ); Mon, 23 May 2022 13:38:18 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5F6BB6E8E4; Mon, 23 May 2022 10:32:29 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 8E5BEB81218; Mon, 23 May 2022 17:31:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EBE38C385AA; Mon, 23 May 2022 17:31:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1653327066; bh=kxOZ5QqWCnpmv5KQaoJ4TOsadG16Vztf+q4rTiMkJ3E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nSRRIbTERNdMxPeLkWXeZDO2DDskToEHFexAVzjg/rJ7jqAMqwk45tETCQgBs0OuS E1OqUxB5cl69cGWixw5KHahh+sm8ImvlpcVEUl7OJZ31I5DThG9muYDWQBQdiLAW+K BjbppH3dI+R25RMmAYD4932CzoX0V7daAm7NlXfg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Lina Wang , "David S. Miller" , Sasha Levin Subject: [PATCH 5.17 146/158] net: fix wrong network header length Date: Mon, 23 May 2022 19:05:03 +0200 Message-Id: <20220523165854.407189203@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220523165830.581652127@linuxfoundation.org> References: <20220523165830.581652127@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Lina Wang [ Upstream commit cf3ab8d4a797960b4be20565abb3bcd227b18a68 ] When clatd starts with ebpf offloaing, and NETIF_F_GRO_FRAGLIST is enable, several skbs are gathered in skb_shinfo(skb)->frag_list. The first skb's ipv6 header will be changed to ipv4 after bpf_skb_proto_6_to_4, network_header\transport_header\mac_header have been updated as ipv4 acts, but other skbs in frag_list didnot update anything, just ipv6 packets. udp_queue_rcv_skb will call skb_segment_list to traverse other skbs in frag_list and make sure right udp payload is delivered to user space. Unfortunately, other skbs in frag_list who are still ipv6 packets are updated like the first skb and will have wrong transport header length. e.g.before bpf_skb_proto_6_to_4,the first skb and other skbs in frag_list has the same network_header(24)& transport_header(64), after bpf_skb_proto_6_to_4, ipv6 protocol has been changed to ipv4, the first skb's network_header is 44,transport_header is 64, other skbs in frag_list didnot change.After skb_segment_list, the other skbs in frag_list has different network_header(24) and transport_header(44), so there will be 20 bytes different from original,that is difference between ipv6 header and ipv4 header. Just change transport_header to be the same with original. Actually, there are two solutions to fix it, one is traversing all skbs and changing every skb header in bpf_skb_proto_6_to_4, the other is modifying frag_list skb's header in skb_segment_list. Considering efficiency, adopt the second one--- when the first skb and other skbs in frag_list has different network_header length, restore them to make sure right udp payload is delivered to user space. Signed-off-by: Lina Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- net/core/skbuff.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 180fa6a26ad4..708cc9b1b176 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -3896,7 +3896,7 @@ struct sk_buff *skb_segment_list(struct sk_buff *skb, unsigned int delta_len = 0; struct sk_buff *tail = NULL; struct sk_buff *nskb, *tmp; - int err; + int len_diff, err; skb_push(skb, -skb_network_offset(skb) + offset); @@ -3936,9 +3936,11 @@ struct sk_buff *skb_segment_list(struct sk_buff *skb, skb_push(nskb, -skb_network_offset(nskb) + offset); skb_release_head_state(nskb); + len_diff = skb_network_header_len(nskb) - skb_network_header_len(skb); __copy_skb_header(nskb, skb); skb_headers_offset_update(nskb, skb_headroom(nskb) - skb_headroom(skb)); + nskb->transport_header += len_diff; skb_copy_from_linear_data_offset(skb, -tnl_hlen, nskb->data - tnl_hlen, offset + tnl_hlen); -- 2.35.1