Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp669085ybg; Mon, 1 Jun 2020 11:13:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxD/QtJS2waOOiIVDHrj5IF/m0K2yV3xIbIjKVZdsIUMzddGCsvrT96quAGr/v46ZWueFX7 X-Received: by 2002:aa7:d79a:: with SMTP id s26mr21231308edq.202.1591035218402; Mon, 01 Jun 2020 11:13:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591035218; cv=none; d=google.com; s=arc-20160816; b=kPg7sR2wzMkJwFhLncXM/7XipwMXQN38SNACnnjAeMGdXxQ4T93WLVcRutVWptBn4v IuRhTldS/ex++q/PqDOHLcLpdgkt2XGiANcFayFKXh9+sKFhdLMsR20CIQZTlYqMX1nx tkDDVoV979+WKFOlD/B3+NBKPE8ofiJjMTph26tTC5d/ok1imy1mqGK7DvgiLY9mUjqe UFYMgopYuiqTcYU+Ucry4NpbpXNmQS0lhvlq457H8c8ernVS/0p394Bwo3NOEW1vgLdZ 02DQNstYgD3hR19nxWm6gvMHILb/J76Xfn4qrGP0EOG+rg52QZoA73xlPKj8UQa3Ba1L tW9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=4fHzRn1diI/EIIRmqcaPWkz90JuVuZQFIhv9y93DydU=; b=WyOXbqx5b2KZ2mAkXOUT4QcqyELm/OZygRSH63uVNLEcvSFb8gNCWJvz9yB4mduk/6 +MBSZ2heNgCGvsbromsrIwVLfZIGvNOXg3uzzVq+DoEVNnXBrRBNn/orE0h4XrbExSN5 t4+rXq+A3uBntduPgvZ875pdLZ+qx2MzFvt+zcwfeWkO5Oc81Ic0j5DQLOmjTxblVnsy aT0vMn3X4VbyeUOllUX8vu5Wm4ntcxAMFANcS0rnypWSQ4GpZe6HA88lEfvgcE/p4cel cT0DuHSPFgT7yn+g/oxKiyEqXsTL7GieHV+L/ttgS2H4LyYdlhkJc1zuvcSrP+pTROeL SqIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=d3zaM4ZE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q14si158810ejt.12.2020.06.01.11.13.14; Mon, 01 Jun 2020 11:13:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=d3zaM4ZE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730512AbgFASKo (ORCPT + 99 others); Mon, 1 Jun 2020 14:10:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:57276 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730972AbgFASK1 (ORCPT ); Mon, 1 Jun 2020 14:10:27 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 086CC2068D; Mon, 1 Jun 2020 18:10:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591035026; bh=NO1fE9qbQO897QXTH+eDr2xuCe1LhEei9ZR1cr4pqYw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=d3zaM4ZE0ckoNsn52H++ce1URs858uVtFCZbI+uMEd/cA7N/0wyIBa3jZ2wNpK4fF tnk4o6VEE+kCbHMqqAzaHwj+R459Nz2sRlQ8rrbBuvFcFh+GGFfCy8gnh06dV5/9e9 Makw+9AU6yl+3pJnGJIug33Z9LsoBaQBgFSh3raM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Xiumei Mu , Xin Long , Steffen Klassert Subject: [PATCH 5.4 120/142] ip_vti: receive ipip packet by calling ip_tunnel_rcv Date: Mon, 1 Jun 2020 19:54:38 +0200 Message-Id: <20200601174050.248686867@linuxfoundation.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200601174037.904070960@linuxfoundation.org> References: <20200601174037.904070960@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Xin Long commit 976eba8ab596bab94b9714cd46d38d5c6a2c660d upstream. In Commit dd9ee3444014 ("vti4: Fix a ipip packet processing bug in 'IPCOMP' virtual tunnel"), it tries to receive IPIP packets in vti by calling xfrm_input(). This case happens when a small packet or frag sent by peer is too small to get compressed. However, xfrm_input() will still get to the IPCOMP path where skb sec_path is set, but never dropped while it should have been done in vti_ipcomp4_protocol.cb_handler(vti_rcv_cb), as it's not an ipcomp4 packet. This will cause that the packet can never pass xfrm4_policy_check() in the upper protocol rcv functions. So this patch is to call ip_tunnel_rcv() to process IPIP packets instead. Fixes: dd9ee3444014 ("vti4: Fix a ipip packet processing bug in 'IPCOMP' virtual tunnel") Reported-by: Xiumei Mu Signed-off-by: Xin Long Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman --- net/ipv4/ip_vti.c | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) --- a/net/ipv4/ip_vti.c +++ b/net/ipv4/ip_vti.c @@ -93,7 +93,28 @@ static int vti_rcv_proto(struct sk_buff static int vti_rcv_tunnel(struct sk_buff *skb) { - return vti_rcv(skb, ip_hdr(skb)->saddr, true); + struct ip_tunnel_net *itn = net_generic(dev_net(skb->dev), vti_net_id); + const struct iphdr *iph = ip_hdr(skb); + struct ip_tunnel *tunnel; + + tunnel = ip_tunnel_lookup(itn, skb->dev->ifindex, TUNNEL_NO_KEY, + iph->saddr, iph->daddr, 0); + if (tunnel) { + struct tnl_ptk_info tpi = { + .proto = htons(ETH_P_IP), + }; + + if (!xfrm4_policy_check(NULL, XFRM_POLICY_IN, skb)) + goto drop; + if (iptunnel_pull_header(skb, 0, tpi.proto, false)) + goto drop; + return ip_tunnel_rcv(tunnel, skb, &tpi, NULL, false); + } + + return -EINVAL; +drop: + kfree_skb(skb); + return 0; } static int vti_rcv_cb(struct sk_buff *skb, int err)