From patchwork Wed Oct 10 15:25:47 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Florian Westphal X-Patchwork-Id: 981950 X-Patchwork-Delegate: pablo@netfilter.org Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netfilter-devel-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=strlen.de Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 42Vd946Yl7z9s8F for ; Thu, 11 Oct 2018 02:21:12 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726666AbeJJWnu (ORCPT ); Wed, 10 Oct 2018 18:43:50 -0400 Received: from Chamillionaire.breakpoint.cc ([146.0.238.67]:47808 "EHLO Chamillionaire.breakpoint.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726562AbeJJWnu (ORCPT ); Wed, 10 Oct 2018 18:43:50 -0400 Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.89) (envelope-from ) id 1gAGIP-0004b1-H5; Wed, 10 Oct 2018 17:21:09 +0200 From: Florian Westphal To: Cc: eyal.birger@gmail.com, Florian Westphal Subject: [PATCH nf-next] netfilter: nf_tables: xfrm: use state family, not hook one Date: Wed, 10 Oct 2018 17:25:47 +0200 Message-Id: <20181010152547.28014-1-fw@strlen.de> X-Mailer: git-send-email 2.18.0 Sender: netfilter-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netfilter-devel@vger.kernel.org Eyal says: doesn't the use of nft_pf(pkt) in this context limit the matching of encapsulated packets to the same family? IIUC when an e.g. IPv6-in-IPv4 packet is matched, the nft_pf(pkt) will be the decapsulated packet family - IPv6 - whereas the state may be IPv4. So this check would not allow matching the 'underlay' address in such cases. I know this was a limitation in xt_policy. but is this intentional in this matcher? or is it possible to use state->props.family when validating the match instead of nft_pf(pkt)? Userspace already tells us which address family it expects to match, so we can just use the real state family rather than the hook family. so change it as suggested above. Reported-by: Eyal Birger Suggested-by: Eyal Birger Fixes: 6c47260250fc6 ("netfilter: nf_tables: add xfrm expression") Signed-off-by: Florian Westphal --- The expression is only in nf-next. net/netfilter/nft_xfrm.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/net/netfilter/nft_xfrm.c b/net/netfilter/nft_xfrm.c index 3cf71a2e375b..5322609f7662 100644 --- a/net/netfilter/nft_xfrm.c +++ b/net/netfilter/nft_xfrm.c @@ -118,12 +118,13 @@ static bool xfrm_state_addr_ok(enum nft_xfrm_keys k, u8 family, u8 mode) static void nft_xfrm_state_get_key(const struct nft_xfrm *priv, struct nft_regs *regs, - const struct xfrm_state *state, - u8 family) + const struct xfrm_state *state) { u32 *dest = ®s->data[priv->dreg]; - if (!xfrm_state_addr_ok(priv->key, family, state->props.mode)) { + if (!xfrm_state_addr_ok(priv->key, + state->props.family, + state->props.mode)) { regs->verdict.code = NFT_BREAK; return; } @@ -169,7 +170,7 @@ static void nft_xfrm_get_eval_in(const struct nft_xfrm *priv, } state = sp->xvec[priv->spnum]; - nft_xfrm_state_get_key(priv, regs, state, nft_pf(pkt)); + nft_xfrm_state_get_key(priv, regs, state); } static void nft_xfrm_get_eval_out(const struct nft_xfrm *priv, @@ -184,7 +185,7 @@ static void nft_xfrm_get_eval_out(const struct nft_xfrm *priv, if (i < priv->spnum) continue; - nft_xfrm_state_get_key(priv, regs, dst->xfrm, nft_pf(pkt)); + nft_xfrm_state_get_key(priv, regs, dst->xfrm); return; }