From patchwork Wed Sep 27 02:02:19 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joao Moreira X-Patchwork-Id: 13399810 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 51A6D1C03 for ; Wed, 27 Sep 2023 02:02:56 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 759641C26A; Tue, 26 Sep 2023 19:02:54 -0700 (PDT) X-IronPort-AV: E=McAfee;i="6600,9927,10845"; a="385565329" X-IronPort-AV: E=Sophos;i="6.03,179,1694761200"; d="scan'208";a="385565329" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Sep 2023 19:02:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10845"; a="725628814" X-IronPort-AV: E=Sophos;i="6.03,179,1694761200"; d="scan'208";a="725628814" Received: from pinksteam.jf.intel.com ([10.165.239.231]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Sep 2023 19:02: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 v2 0/2] Prevent potential write out of bounds Date: Tue, 26 Sep 2023 19:02:19 -0700 Message-ID: <20230927020221.85292-1-joao@overdrivepizza.com> X-Mailer: git-send-email 2.42.0 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NEUTRAL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net From: Joao Moreira The function flow_rule_alloc in net/core/flow_offload.c [2] gets an unsigned int num_actions (line 10) and later traverses the actions in the rule (line 24) setting hw.stats to FLOW_ACTION_HW_STATS_DONT_CARE. Within the same file, the loop in the line 24 compares a signed int (i) to an unsigned int (num_actions), and then uses i as an array index. If an integer overflow happens, then the array within the loop is wrongly indexed, causing a write out of bounds. After checking with maintainers, it seems that the front-end caps the maximum value of num_action, thus it is not possible to reach the given write out of bounds, yet, still, to prevent disasters it is better to fix the signedness here. Similarly, also it is also good to ensure that an overflow won't happen in net/netfilter/nf_tables_offload.c's function nft_flow_rule_create by making the variable unsigned and ensuring that it returns an error if its value reaches UINT_MAX. 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/ Tks, Joao Moreira (2): Make loop indexes unsigned Make num_actions unsigned net/core/flow_offload.c | 4 ++-- net/netfilter/nf_tables_offload.c | 6 +++++- 2 files changed, 7 insertions(+), 3 deletions(-)