Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1784129pxp; Mon, 7 Mar 2022 02:13:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJybJ57Fml1d3S0ZJKT04ydjjltReA6y4+XTLnPYQLyEH75dgF4GAnywf5HGwNIlIEkLY0rF X-Received: by 2002:a17:907:d06:b0:6da:2902:e9ad with SMTP id gn6-20020a1709070d0600b006da2902e9admr8712300ejc.566.1646648033497; Mon, 07 Mar 2022 02:13:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646648033; cv=none; d=google.com; s=arc-20160816; b=dLVHRNjM8qW34taEuWuEWLffhJviZUgPvhr8MgUOVeeFDdXehgr4qz7QH67AB2Zsnu W272b9FX6hVvshQTa/rNT4d0EJqXeDNCY6RqykmWAzBpNLLVjwSR8TSAPV20faTA0w9S Ucxh9PIOw4bVnpyczUx6MEfQz7ff1Eu8yl9amBGQRIYBgNrZRgog6VunjM2U0cTGfxM7 0nQ8OUR2gOzCorTAZ8jPHjfFqzeVU3oTs8fPZeEeerKfCUaAkOFltctUkmUG/C8hS+8N MGki5ZiZMn7hkrbOnK5hIDAyDmcgB3XRD9WJcU+mDqt0i75qnf1FssemDL7YSEL6LIv8 Brsw== 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=egNmMcgV2jIaCH33O0uYPkMgrRTzixVcFiEeLNDORDs=; b=KYmPOUEIh4GYA6DyVyjzoTQlgfjHmnKpOxFkF2NyWI5rU+VwzWGzB/2/+k1L0mRHbV yY3omCKIV5BgjUf7Q5EG18qIDpriWq/1RNJd56lJ3agYJA4iUTi7R9LoowQLTz4rkZbU FsIbydrZ0XTE2gYAry8OHMF8xiVB6NPoZJJkM266wMfk5jQX0mWrLHua+GrWJoRQoaWt HTPpkWVa72TCn8utrWiu9cz2xXhQliK7Z3YOi3qFO/zrNzgk5WfhDWPsLjtA2u9QwlJB /hB2HEtaPmSXtebmh/NXoVM9jT8C4PF6uoMIHU3Z0okxNymaC9KWFZ/k5RRME4BnL8Ds zegg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=JcRtprgG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z1-20020a50eb41000000b00410a2e77995si9074595edp.15.2022.03.07.02.13.31; Mon, 07 Mar 2022 02:13:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=JcRtprgG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233867AbiCGJpd (ORCPT + 99 others); Mon, 7 Mar 2022 04:45:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54394 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237550AbiCGJfW (ORCPT ); Mon, 7 Mar 2022 04:35:22 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D66116D3BB; Mon, 7 Mar 2022 01:31:08 -0800 (PST) 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 1A11CB810C2; Mon, 7 Mar 2022 09:30:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8303DC340E9; Mon, 7 Mar 2022 09:30:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646645451; bh=VhGi8MFyHuo28m+9+2Z+7/z5004SCo//JCYm45CBOqA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JcRtprgGIYhHg2OVmlo73sa1+5Srfl88H2eMc2SZyDsNPQKNri6RmiG/6QfgJtuZs iess1sY2CUp/VC2f/f+pRMlYfZ4gQLx7sxnkyCM1JZoezUyk8mK40AwLsA7oAFcs6a FPplc9edVZ8Bobfsq5I9pVAQ4R/rO3DlDkHtUf2M= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jiri Bohac , Steffen Klassert Subject: [PATCH 5.10 036/105] xfrm: fix MTU regression Date: Mon, 7 Mar 2022 10:18:39 +0100 Message-Id: <20220307091645.201437369@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220307091644.179885033@linuxfoundation.org> References: <20220307091644.179885033@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=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,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: Jiri Bohac commit 6596a0229541270fb8d38d989f91b78838e5e9da upstream. Commit 749439bfac6e1a2932c582e2699f91d329658196 ("ipv6: fix udpv6 sendmsg crash caused by too small MTU") breaks PMTU for xfrm. A Packet Too Big ICMPv6 message received in response to an ESP packet will prevent all further communication through the tunnel if the reported MTU minus the ESP overhead is smaller than 1280. E.g. in a case of a tunnel-mode ESP with sha256/aes the overhead is 92 bytes. Receiving a PTB with MTU of 1371 or less will result in all further packets in the tunnel dropped. A ping through the tunnel fails with "ping: sendmsg: Invalid argument". Apparently the MTU on the xfrm route is smaller than 1280 and fails the check inside ip6_setup_cork() added by 749439bf. We found this by debugging USGv6/ipv6ready failures. Failing tests are: "Phase-2 Interoperability Test Scenario IPsec" / 5.3.11 and 5.4.11 (Tunnel Mode: Fragmentation). Commit b515d2637276a3810d6595e10ab02c13bfd0b63a ("xfrm: xfrm_state_mtu should return at least 1280 for ipv6") attempted to fix this but caused another regression in TCP MSS calculations and had to be reverted. The patch below fixes the situation by dropping the MTU check and instead checking for the underflows described in the 749439bf commit message. Signed-off-by: Jiri Bohac Fixes: 749439bfac6e ("ipv6: fix udpv6 sendmsg crash caused by too small MTU") Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman --- net/ipv6/ip6_output.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -1432,8 +1432,6 @@ static int ip6_setup_cork(struct sock *s if (np->frag_size) mtu = np->frag_size; } - if (mtu < IPV6_MIN_MTU) - return -EINVAL; cork->base.fragsize = mtu; cork->base.gso_size = ipc6->gso_size; cork->base.tx_flags = 0; @@ -1495,8 +1493,6 @@ static int __ip6_append_data(struct sock fragheaderlen = sizeof(struct ipv6hdr) + rt->rt6i_nfheader_len + (opt ? opt->opt_nflen : 0); - maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen - - sizeof(struct frag_hdr); headersize = sizeof(struct ipv6hdr) + (opt ? opt->opt_flen + opt->opt_nflen : 0) + @@ -1504,6 +1500,13 @@ static int __ip6_append_data(struct sock sizeof(struct frag_hdr) : 0) + rt->rt6i_nfheader_len; + if (mtu < fragheaderlen || + ((mtu - fragheaderlen) & ~7) + fragheaderlen < sizeof(struct frag_hdr)) + goto emsgsize; + + maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen - + sizeof(struct frag_hdr); + /* as per RFC 7112 section 5, the entire IPv6 Header Chain must fit * the first fragment */