From patchwork Wed Sep 27 16:47:14 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joao Moreira X-Patchwork-Id: 13401406 X-Patchwork-Delegate: kuba@kernel.org Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A38B03C6BF for ; Wed, 27 Sep 2023 16:47:38 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3FA85DE; Wed, 27 Sep 2023 09:47:36 -0700 (PDT) X-IronPort-AV: E=McAfee;i="6600,9927,10846"; a="366934590" X-IronPort-AV: E=Sophos;i="6.03,181,1694761200"; d="scan'208";a="366934590" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2023 09:47:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10846"; a="922853707" X-IronPort-AV: E=Sophos;i="6.03,181,1694761200"; d="scan'208";a="922853707" Received: from pinksteam.jf.intel.com ([10.165.239.231]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2023 09:47:35 -0700 From: joao@overdrivepizza.com To: pablo@netfilter.org, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, joao@overdrivepizza.com Cc: kadlec@netfilter.org, fw@strlen.de, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, rkannoth@marvell.com, wojciech.drewek@intel.com, steen.hegenlund@microhip.com, keescook@chromium.org, Joao Moreira Subject: [PATCH v3 1/2] Make loop indexes unsigned Date: Wed, 27 Sep 2023 09:47:14 -0700 Message-ID: <20230927164715.76744-2-joao@overdrivepizza.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20230927164715.76744-1-joao@overdrivepizza.com> References: <20230927164715.76744-1-joao@overdrivepizza.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NEUTRAL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net X-Patchwork-Delegate: kuba@kernel.org From: Joao Moreira Both flow_rule_alloc and offload_action_alloc functions received an unsigned num_actions parameters which are then operated within a loop. The index of this loop is declared as a signed int. If it was possible to pass a large enough num_actions to these functions, it would lead to an out of bounds write. After checking with maintainers, it was mentioned that front-end will cap the num_actions value and that it is not possible to reach this function with such a large number. Yet, for correctness, it is still better to fix this. This issue was observed by the commit author while reviewing a write-up regarding a CVE within the same subsystem [1]. 1 - https://nickgregory.me/post/2022/03/12/cve-2022-25636/ Signed-off-by: Joao Moreira --- net/core/flow_offload.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/core/flow_offload.c b/net/core/flow_offload.c index bc5169482710..bc3f53a09d8f 100644 --- a/net/core/flow_offload.c +++ b/net/core/flow_offload.c @@ -10,7 +10,7 @@ struct flow_rule *flow_rule_alloc(unsigned int num_actions) { struct flow_rule *rule; - int i; + unsigned int i; rule = kzalloc(struct_size(rule, action.entries, num_actions), GFP_KERNEL); @@ -31,7 +31,7 @@ EXPORT_SYMBOL(flow_rule_alloc); struct flow_offload_action *offload_action_alloc(unsigned int num_actions) { struct flow_offload_action *fl_action; - int i; + unsigned int i; fl_action = kzalloc(struct_size(fl_action, action.entries, num_actions), GFP_KERNEL); From patchwork Wed Sep 27 16:47:15 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joao Moreira X-Patchwork-Id: 13401407 X-Patchwork-Delegate: kuba@kernel.org Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A3423E46A for ; Wed, 27 Sep 2023 16:47:39 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9186CEB; Wed, 27 Sep 2023 09:47:37 -0700 (PDT) X-IronPort-AV: E=McAfee;i="6600,9927,10846"; a="366934607" X-IronPort-AV: E=Sophos;i="6.03,181,1694761200"; d="scan'208";a="366934607" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2023 09:47:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10846"; a="922853712" X-IronPort-AV: E=Sophos;i="6.03,181,1694761200"; d="scan'208";a="922853712" Received: from pinksteam.jf.intel.com ([10.165.239.231]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2023 09:47:37 -0700 From: joao@overdrivepizza.com To: pablo@netfilter.org, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, joao@overdrivepizza.com Cc: kadlec@netfilter.org, fw@strlen.de, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, rkannoth@marvell.com, wojciech.drewek@intel.com, steen.hegenlund@microhip.com, keescook@chromium.org, Joao Moreira Subject: [PATCH v3 2/2] Make num_actions unsigned Date: Wed, 27 Sep 2023 09:47:15 -0700 Message-ID: <20230927164715.76744-3-joao@overdrivepizza.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20230927164715.76744-1-joao@overdrivepizza.com> References: <20230927164715.76744-1-joao@overdrivepizza.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NEUTRAL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net X-Patchwork-Delegate: kuba@kernel.org From: Joao Moreira Currently, in nft_flow_rule_create function, num_actions is a signed integer. Yet, it is processed within a loop which increments its value. To prevent an overflow from occurring, make it unsigned and also check if it reaches 256 when being incremented. Accordingly to discussions around v2, 256 actions are more than enough for the frontend actions. After checking with maintainers, it was mentioned that front-end will cap the num_actions value and that it is not possible to reach such condition for an overflow. Yet, for correctness, it is still better to fix this. This issue was observed by the commit author while reviewing a write-up regarding a CVE within the same subsystem [1]. 1 - https://nickgregory.me/post/2022/03/12/cve-2022-25636/ Signed-off-by: Joao Moreira --- net/netfilter/nf_tables_offload.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/net/netfilter/nf_tables_offload.c b/net/netfilter/nf_tables_offload.c index 12ab78fa5d84..9a86db1f0e07 100644 --- a/net/netfilter/nf_tables_offload.c +++ b/net/netfilter/nf_tables_offload.c @@ -90,7 +90,8 @@ struct nft_flow_rule *nft_flow_rule_create(struct net *net, { struct nft_offload_ctx *ctx; struct nft_flow_rule *flow; - int num_actions = 0, err; + unsigned int num_actions = 0; + int err; struct nft_expr *expr; expr = nft_expr_first(rule); @@ -99,6 +100,10 @@ struct nft_flow_rule *nft_flow_rule_create(struct net *net, expr->ops->offload_action(expr)) num_actions++; + /* 2^8 is enough for frontend actions, avoid overflow */ + if (num_actions == 256) + return ERR_PTR(-ENOMEM); + expr = nft_expr_next(expr); }