From patchwork Wed Apr 27 12:08:01 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jiri Benc X-Patchwork-Id: 615581 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3qvzJW3Y3Fz9t6S for ; Wed, 27 Apr 2016 22:08:43 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752663AbcD0MIl (ORCPT ); Wed, 27 Apr 2016 08:08:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35714 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752316AbcD0MIk (ORCPT ); Wed, 27 Apr 2016 08:08:40 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 96A004DB01; Wed, 27 Apr 2016 12:08:39 +0000 (UTC) Received: from griffin.upir.cz (ovpn-204-92.brq.redhat.com [10.40.204.92]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3RC8aR4004098; Wed, 27 Apr 2016 08:08:37 -0400 From: Jiri Benc To: netdev@vger.kernel.org Cc: Pravin Shelar , Thomas Graf , Tom Herbert Subject: [PATCH net] gre: reject GUE and FOU in collect metadata mode Date: Wed, 27 Apr 2016 14:08:01 +0200 Message-Id: <7280f5aa7ec83653cdf7f0484fb9e696bc8c89e8.1461758705.git.jbenc@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org The collect metadata mode does not support GUE nor FOU. This might be implemented later; until then, we should reject such config. I think this is okay to be changed. It's unlikely anyone has such configuration (as it doesn't work anyway) and we may need a way to distinguish whether it's supported or not by the kernel later. For backwards compatibility with iproute2, it's not possible to just check the attribute presence (iproute2 always includes the attribute), the actual value has to be checked, too. Fixes: 2e15ea390e6f4 ("ip_gre: Add support to collect tunnel metadata.") Signed-off-by: Jiri Benc --- Discovered this only after I already sent v3 of the previous gre set. Submitting this patch on its own, it's an indepent fix anyway (though fixing the same commit). --- net/ipv4/ip_gre.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c index f973e0a58993..f502d34bcb40 100644 --- a/net/ipv4/ip_gre.c +++ b/net/ipv4/ip_gre.c @@ -948,6 +948,11 @@ static int ipgre_tunnel_validate(struct nlattr *tb[], struct nlattr *data[]) if (flags & (GRE_VERSION|GRE_ROUTING)) return -EINVAL; + if (data[IFLA_GRE_COLLECT_METADATA] && + data[IFLA_GRE_ENCAP_TYPE] && + nla_get_u16(data[IFLA_GRE_ENCAP_TYPE]) != TUNNEL_ENCAP_NONE) + return -EINVAL; + return 0; }