Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp4445222imw; Tue, 19 Jul 2022 06:47:47 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sVs7kIr/jU+a1iDuLUwCjM5jlCGt+5QM/K6FfeAbCgu/gxlFE9i089xg/Ag/rvfFlhkJtK X-Received: by 2002:aa7:c650:0:b0:43a:2c9a:fd1f with SMTP id z16-20020aa7c650000000b0043a2c9afd1fmr43870104edr.318.1658238467253; Tue, 19 Jul 2022 06:47:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658238467; cv=none; d=google.com; s=arc-20160816; b=AzMCJSKUbnhqyKDSi5DRQVYS2ZXSxTWFE4cjaFOIU4Au0LqIk5YuTWZb58QKhMaoqN ErTOvw7LMfZzEyyx2gg9PhFTAzn8zBeSg2XNkA7CxqUsddvo3E/rOw2JXkmULLNr8ope boSLuT62KQeLx/OC/P4oOhHtsWN+jEHqR1TwXuCXMAdVfzToOTcCugxFcJEIsTsmeX14 /aqAxUn9eGKEQ9781UKUS5KX/sCQpLcqPYYdP0yU12zaogS4DJqdI8CASbUsKL4gUGeT l0fQWNwdVnnRbHOsGCA3crac4HodO0Yb9qcjF8Q1P0py72mWqhBU8CFfsBJGfUE+CkXk WTYw== 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=vDs9OSwRjLozoN5jsHiPxx9YF/V0btBbPklQn6xP+Bw=; b=OQjk2uA1/fkyxKCe+R35KWKP1432G4a9BMdfl3f4fTEPqmAnoBGH9BHr1KDGqy1K2+ 0Jad7vc86TzLu7UHr/1WZOdmJ+oha9OO9/q4qQN3iz1G8NZ4dx0MBGxBDNuedG/8Hkis f9hctvKM30frRpJ03mlE2t69ohrgNesFL16bHdXxa6ZY74/hfHcd76z6naXdRrE03/H5 2h8uIanZwUH+IdTZeaq5yxxBZXNhjCAaqjVM2/AA1u9ue+6B3GZWPIO6n/frwugOEaN+ 6Ejz2X6dj+NrHS3cltMfrj2ADLELTmUU5Di/oVozLIy1BgXy6fKLlO578RsGfNGIKxZs nG3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="tLXM/2Ej"; 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 g11-20020aa7d1cb000000b0043a734c7014si16829381edp.78.2022.07.19.06.47.22; Tue, 19 Jul 2022 06:47:47 -0700 (PDT) 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="tLXM/2Ej"; 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 S237998AbiGSMoC (ORCPT + 99 others); Tue, 19 Jul 2022 08:44:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53444 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241119AbiGSMnW (ORCPT ); Tue, 19 Jul 2022 08:43:22 -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 86065820F0; Tue, 19 Jul 2022 05:16:55 -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 E8E36B81B1A; Tue, 19 Jul 2022 12:16:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 36091C341CA; Tue, 19 Jul 2022 12:16:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1658233013; bh=GqYSiyEiYN54B9KbL1CA43tpPPB30YDlNdA9ZXdKhCM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tLXM/2EjNB5IQ6nw+3sNmf0GYUSh5RdHRk9eLqyYIaHSODTHIJfNyQYU8CfRpxD4C duLKiHniluYiFn8R/Yqe8ODv0fUADou+QHn42FiuOGNNbuKxarY8TATduygffOrLa+ 4P15orxl27KYlObAZAKmPMABnqlHe8Ib0drC5liY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Radim Hrazdil , Florian Westphal , Pablo Neira Ayuso , Sasha Levin Subject: [PATCH 5.15 119/167] netfilter: br_netfilter: do not skip all hooks with 0 priority Date: Tue, 19 Jul 2022 13:54:11 +0200 Message-Id: <20220719114708.085973251@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220719114656.750574879@linuxfoundation.org> References: <20220719114656.750574879@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.8 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 autolearn=ham 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: Florian Westphal [ Upstream commit c2577862eeb0be94f151f2f1fff662b028061b00 ] When br_netfilter module is loaded, skbs may be diverted to the ipv4/ipv6 hooks, just like as if we were routing. Unfortunately, bridge filter hooks with priority 0 may be skipped in this case. Example: 1. an nftables bridge ruleset is loaded, with a prerouting hook that has priority 0. 2. interface is added to the bridge. 3. no tcp packet is ever seen by the bridge prerouting hook. 4. flush the ruleset 5. load the bridge ruleset again. 6. tcp packets are processed as expected. After 1) the only registered hook is the bridge prerouting hook, but its not called yet because the bridge hasn't been brought up yet. After 2), hook order is: 0 br_nf_pre_routing // br_netfilter internal hook 0 chain bridge f prerouting // nftables bridge ruleset The packet is diverted to br_nf_pre_routing. If call-iptables is off, the nftables bridge ruleset is called as expected. But if its enabled, br_nf_hook_thresh() will skip it because it assumes that all 0-priority hooks had been called previously in bridge context. To avoid this, check for the br_nf_pre_routing hook itself, we need to resume directly after it, even if this hook has a priority of 0. Unfortunately, this still results in different packet flow. With this fix, the eval order after in 3) is: 1. br_nf_pre_routing 2. ip(6)tables (if enabled) 3. nftables bridge but after 5 its the much saner: 1. nftables bridge 2. br_nf_pre_routing 3. ip(6)tables (if enabled) Unfortunately I don't see a solution here: It would be possible to move br_nf_pre_routing to a higher priority so that it will be called later in the pipeline, but this also impacts ebtables evaluation order, and would still result in this very ordering problem for all nftables-bridge hooks with the same priority as the br_nf_pre_routing one. Searching back through the git history I don't think this has ever behaved in any other way, hence, no fixes-tag. Reported-by: Radim Hrazdil Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin --- net/bridge/br_netfilter_hooks.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c index 68c0d0f92890..10a2c7bca719 100644 --- a/net/bridge/br_netfilter_hooks.c +++ b/net/bridge/br_netfilter_hooks.c @@ -1012,9 +1012,24 @@ int br_nf_hook_thresh(unsigned int hook, struct net *net, return okfn(net, sk, skb); ops = nf_hook_entries_get_hook_ops(e); - for (i = 0; i < e->num_hook_entries && - ops[i]->priority <= NF_BR_PRI_BRNF; i++) - ; + for (i = 0; i < e->num_hook_entries; i++) { + /* These hooks have already been called */ + if (ops[i]->priority < NF_BR_PRI_BRNF) + continue; + + /* These hooks have not been called yet, run them. */ + if (ops[i]->priority > NF_BR_PRI_BRNF) + break; + + /* take a closer look at NF_BR_PRI_BRNF. */ + if (ops[i]->hook == br_nf_pre_routing) { + /* This hook diverted the skb to this function, + * hooks after this have not been run yet. + */ + i++; + break; + } + } nf_hook_state_init(&state, hook, NFPROTO_BRIDGE, indev, outdev, sk, net, okfn); -- 2.35.1