From patchwork Tue Mar 22 21:45:20 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12789218 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1250DC433FE for ; Tue, 22 Mar 2022 21:45:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A4DF6B0130; Tue, 22 Mar 2022 17:45:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 92DBE6B0131; Tue, 22 Mar 2022 17:45:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81F736B0132; Tue, 22 Mar 2022 17:45:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0223.hostedemail.com [216.40.44.223]) by kanga.kvack.org (Postfix) with ESMTP id 7243A6B0130 for ; Tue, 22 Mar 2022 17:45:22 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 38CBF1828AE47 for ; Tue, 22 Mar 2022 21:45:22 +0000 (UTC) X-FDA: 79273353684.16.2EC00F4 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf25.hostedemail.com (Postfix) with ESMTP id C8393A0035 for ; Tue, 22 Mar 2022 21:45:21 +0000 (UTC) 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 dfw.source.kernel.org (Postfix) with ESMTPS id 4472E6119A; Tue, 22 Mar 2022 21:45:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 06E1EC340EC; Tue, 22 Mar 2022 21:45:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1647985521; bh=jH8dF7GDqUGZPmmXDZ4LtM2Kj40YUDVUvC12nBofJUE=; h=Date:To:From:In-Reply-To:Subject:From; b=0w+vLIgBJ6Y0OOXMHFc2ZCycmpK2I/yanNMe6iD9OLNpVDCf1NyvXdeGRWotLn1p3 R7ZtxbsbKPGx8Wju5EWlwV8ttD1E+Ow6Ud+4EpMvprE6p8J1/t2EMCaPVxLBVKXMIo 2GGhH1+aM0pkv5wOPJmjzctEMoFnNPMp9QtxEJRk= Date: Tue, 22 Mar 2022 14:45:20 -0700 To: yaozhenguo1@gmail.com,mhocko@suse.com,liuyuntao10@huawei.com,dan.carpenter@oracle.com,baolin.wang@linux.alibaba.com,mike.kravetz@oracle.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220322143803.04a5e59a07e48284f196a2f9@linux-foundation.org> Subject: [patch 134/227] hugetlb: clean up potential spectre issue warnings Message-Id: <20220322214521.06E1EC340EC@smtp.kernel.org> X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: mkp46o5156mwc68c4w5xrohpqt3n5dk3 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=0w+vLIgB; dmarc=none; spf=pass (imf25.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-Rspamd-Queue-Id: C8393A0035 X-HE-Tag: 1647985521-337311 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Mike Kravetz Subject: hugetlb: clean up potential spectre issue warnings Recently introduced code allows numa nodes to be specified on the kernel command line for hugetlb allocations or CMA reservations. The node values are user specified and used as indicies into arrays. This generated the following smatch warnings: mm/hugetlb.c:4170 hugepages_setup() warn: potential spectre issue 'default_hugepages_in_node' [w] mm/hugetlb.c:4172 hugepages_setup() warn: potential spectre issue 'parsed_hstate->max_huge_pages_node' [w] mm/hugetlb.c:6898 cmdline_parse_hugetlb_cma() warn: potential spectre issue 'hugetlb_cma_size_in_node' [w] (local cap) Clean up by using array_index_nospec to sanitize array indicies. The routine cmdline_parse_hugetlb_cma has the same overflow/truncation issue addressed in [1]. That is also fixed with this change. [1] https://lore.kernel.org/linux-mm/20220209134018.8242-1-liuyuntao10@huawei.com/ As Michal pointed out, this is unlikely to be exploitable because it is __init code. But the patch suppresses the warnings. [mike.kravetz@oracle.com: v2] Link: https://lkml.kernel.org/r/20220218212946.35441-1-mike.kravetz@oracle.com Link: https://lkml.kernel.org/r/20220217234218.192885-1-mike.kravetz@oracle.com Signed-off-by: Mike Kravetz Cc: Baolin Wang Cc: Zhenguo Yao Cc: Liu Yuntao Cc: Dan Carpenter Cc: Michal Hocko Signed-off-by: Andrew Morton --- mm/hugetlb.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/mm/hugetlb.c~hugetlb-clean-up-potential-spectre-issue-warnings +++ a/mm/hugetlb.c @@ -31,6 +31,7 @@ #include #include #include +#include #include #include @@ -4161,7 +4162,7 @@ static int __init hugepages_setup(char * } if (tmp >= nr_online_nodes) goto invalid; - node = tmp; + node = array_index_nospec(tmp, nr_online_nodes); p += count + 1; /* Parse hugepages */ if (sscanf(p, "%lu%n", &tmp, &count) != 1) @@ -6889,9 +6890,9 @@ static int __init cmdline_parse_hugetlb_ break; if (s[count] == ':') { - nid = tmp; - if (nid < 0 || nid >= MAX_NUMNODES) + if (tmp >= MAX_NUMNODES) break; + nid = array_index_nospec(tmp, MAX_NUMNODES); s += count + 1; tmp = memparse(s, &s);