Received: by 2002:a05:7412:a9a3:b0:f9:327e:43ab with SMTP id o35csp16027rdh; Mon, 18 Dec 2023 03:01:23 -0800 (PST) X-Google-Smtp-Source: AGHT+IFbZ4qmDOn8YlXz4bToK+q7cClgSSboRVZuVdrCyfvmedZm7lMLz/r9FLpOYh8ctIJa0iQP X-Received: by 2002:a05:6102:3c84:b0:466:8cd2:c337 with SMTP id c4-20020a0561023c8400b004668cd2c337mr821239vsv.69.1702897283653; Mon, 18 Dec 2023 03:01:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702897283; cv=none; d=google.com; s=arc-20160816; b=cJyJRzLQE4MoIfVIjqJuUAAjBpRBvzuWWY2e45+kHJwWcpi8+1t/nbnfVHgsa66o+r np8pFEcN14GHkOHF3xtCTRJKqvkq2tXdfad+ui5gmgxmhQBGKqY1jxZuDak9xtu3axEo mmZhdKtFAp/auer5y4iNLDj+O6C2/ha2E2zu+cSCrsW6jjbZv3LPMUjno7Q260wKl/sc /4JvsbrynoD8hhVtbqKE1qNeQ6zNglaJL8MPmBhu7MPRrNPx6w6DxgggBf3rE8yxze8c /zfc/bpQfOAXn8rvwmvrQUZ/XmKwD2BOKyDiW+lo6UjoUdup8gbIrSKtSatc1QcJ17tf 3U0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=9MislW/VTHMhefmK6Iqo/Up4czJxNgIaGxopjjhZWt8=; fh=zq/kTYSb4kHUAaxkWUbvmqC+sl7O3x4rrdIXSgxAw+w=; b=EVlij6rUE1VuaXY4ZW7UGQtL5txamcvCvaORPfY5xdFBIabAM9DS2lk0E4I5fWqA9a rSmxsBqg1K5gBmdSgryjNLrWy/0jMlFBcY/ld2Ahf9WB3DtYXPhNLGslO1C3lyLdSkZ3 bVyrr1kNKABqTyIptKkMWeq5eOi4tBoEy7/iMmzh1EO9C7vrlrPxznnUIIhBEf67teyG Uf3DWIRWjOV1jiUrojQl/BiQuClN44k/4+YPz2yktvJzX764Hlhimk4NPvmGW0Y2P/9r 3t0sLRnSH5lGbHB7lJ4BjX5QZ//pcdNh1o5jk+5pFBIM3scOWY1a1qKDN8TH1OFKXZ+a wJSA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-3396-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-3396-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=easystack.cn Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id v4-20020a056102226400b00466917e0268si158462vsd.461.2023.12.18.03.01.23 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Dec 2023 03:01:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-3396-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-3396-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-3396-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=easystack.cn Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 265881C22C01 for ; Mon, 18 Dec 2023 11:01:23 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4D96D1864C; Mon, 18 Dec 2023 11:01:16 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from mail-m92231.xmail.ntesmail.com (mail-m92231.xmail.ntesmail.com [103.126.92.231]) (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 1D01D179B4 for ; Mon, 18 Dec 2023 11:01:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=easystack.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=easystack.cn Received: from [10.9.0.122] (unknown [211.103.144.18]) by mail-m3159.qiye.163.com (Hmail) with ESMTPA id B9B196402AA; Mon, 18 Dec 2023 16:31:57 +0800 (CST) Message-ID: <2fc2ad7d-13be-4a9a-b984-67b1bf04c56b@easystack.cn> Date: Mon, 18 Dec 2023 16:31:57 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] kexec: avoid out of bounds in crash_exclude_mem_range() Content-Language: en-US To: Baoquan He Cc: Vivek Goyal , Dave Young , kexec@lists.infradead.org, linux-kernel@vger.kernel.org References: <20231127025641.62210-1-fuqiang.wang@easystack.cn> From: fuqiang wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFJQjdXWS1ZQUlXWQ8JGhUIEh9ZQVkZSRlJVhgYSk8eH0NPGUIZTlUZERMWGhIXJBQOD1 lXWRgSC1lBWUlKSlVKS0hVSk9PVUpDWVdZFhoPEhUdFFlBWU9LSFVKTU9JTE5VSktLVUpCS0tZBg ++ X-HM-Tid: 0a8c7c0da4b2009fkurmb9b196402aa X-HM-MType: 1 X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6MT46Eyo*FjEzGQwBQi48AhlM F00aCS9VSlVKTEtJQ0NDSEpCS0tLVTMWGhIXVR0OChIaFRxVDBoVHDseGggCCA8aGBBVGBVFWVdZ EgtZQVlJSkpVSktIVUpPT1VKQ1lXWQgBWUFMTE1KNwY+ 在 2023/12/14 18:29, Baoquan He 写道: > On 11/30/23 at 09:20pm, fuqiang wang wrote: >> On 2023/11/30 15:44, Baoquan He wrote: >>> On 11/27/23 at 10:56am, fuqiang wang wrote: >>>> When the split happened, judge whether mem->nr_ranges is equal to >>>> mem->max_nr_ranges. If it is true, return -ENOMEM. >>>> >>>> The advantage of doing this is that it can avoid array bounds caused by >>>> some bugs. E.g., Before commit 4831be702b95 ("arm64/kexec: Fix missing >>>> extra range for crashkres_low."), reserve both high and low memories for >>>> the crashkernel may cause out of bounds. >>>> >>>> On the other hand, move this code before the split to ensure that the >>>> array will not be changed when return error. >>> If out of array boundary is caused, means the laoding failed, whether >>> the out of boundary happened or not. I don't see how this code change >>> makes sense. Do I miss anything? >>> >>> Thanks >>> Baoquan >>> >> Hi baoquan, >> >> In some configurations, out of bounds may not cause crash_exclude_mem_range() >> returns error, then the load will succeed. >> >> E.g. >> There is a cmem before execute crash_exclude_mem_range(): >> >>   cmem = { >>     max_nr_ranges = 3 >>     nr_ranges = 2 >>     ranges = { >>        {start = 1,      end = 1000} >>        {start = 1001,    end = 2000} >>     } >>   } >> >> After executing twice crash_exclude_mem_range() with the start/end params >> 100/200, 300/400 respectively, the cmem will be: >> >>   cmem = { >>     max_nr_ranges = 3 >>     nr_ranges = 4                    <== nr_ranges > max_nr_ranges >>     ranges = { >>       {start = 1,       end = 99  } >>       {start = 201,     end = 299 } >>       {start = 401,     end = 1000} >>       {start = 1001,    end = 2000}  <== OUT OF BOUNDS >>     } >>   } > Let me borrow your example and copy them here, but I will switch the > order of start/end params 100/200, 300/400 executing at below: > > There is a cmem before execute crash_exclude_mem_range(): > >   cmem = { >     max_nr_ranges = 3 >     nr_ranges = 2 >     ranges = { >        {start = 1,      end = 1000} >        {start = 1001,    end = 2000} >     } >   } > > After executing twice crash_exclude_mem_range() with the start/end params > 300/400, the cmem will be: > >   cmem = { >     max_nr_ranges = 3 >     nr_ranges = 3                    <== nr_ranges == max_nr_ranges >     ranges = { >       {start = 1,       end = 299  } i=0 >       {start = 401,     end = 1000} i=1 >       {start = 1001,    end = 2000}  i=2 >     } >   } > When it's executing the 100/200 excluding, we have: > >   cmem = { >     max_nr_ranges = 3 >     nr_ranges = 4                    <== nr_ranges > max_nr_ranges >     ranges = { >       {start = 1,       end = 99  } i=0 >       {start = 401,     end = 1000} >       {start = 1001,    end = 2000} >     } >   } > > Then splitting happened, i == 0, then for loop is broken and jump out. > Then we have the condition checking here: > > /* Split happened */ > if (i == mem->max_nr_ranges - 1) > return -ENOMEM; > > Obviously the conditonal checking is incorrect (given the i == 0 in > above case), it should be > > /* Split happened */ > if (mem->nr_ranges == mem->max_nr_ranges) > return -ENOMEM; > > So, now there are two things which need be combed up in > crash_exclude_mem_range(): > > 1) the above conditional check is incorrect, need be fixed; > 2) whether we need have the cmem->ranges[] partly changed, or keep it > unchanged when OOB happened; Hi baoquan, I'm sorry, I would like to confirm if I misunderstood the meaning of your comment or not.  What you mean is that you have agreed to merge the patch, but before that, it needs to be explained in detail in the commit message. Is this understanding correct? > And also the incorrect handling in crash_setup_memmap_entries(): > 1) the insufficient array slot in crash_setup_memmap_entries(); > 2) the uninitialized cmem->max_nr_ranges; > If this patch can be merged, the issue of the uninitialized cmem->max_nr_ranges must be resolved before the patch is merged because this patch requires a initialized max_nr_ranges value. I am willing to take on the task of addressing those issues. Thanks fuqiang >> When an out of bounds occurs during the second execution, the function will not >> return error. >> >> Additionally, when the function returns error, means the load failed. It seems >> meaningless to keep the original data unchanged. But in my opinion, this will >> make this function more rigorous and more versatile. (However, I am not sure if >> it is self-defeating and I hope to receive more suggestions). >> >> Thanks >> fuqiang >> >> >>>> Signed-off-by: fuqiang wang >>>> --- >>>> kernel/crash_core.c | 6 +++--- >>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/kernel/crash_core.c b/kernel/crash_core.c >>>> index efe87d501c8c..ffdc246cf425 100644 >>>> --- a/kernel/crash_core.c >>>> +++ b/kernel/crash_core.c >>>> @@ -611,6 +611,9 @@ int crash_exclude_mem_range(struct crash_mem *mem, >>>> } >>>> if (p_start > start && p_end < end) { >>>> + /* Split happened */ >>>> + if (mem->nr_ranges == mem->max_nr_ranges) >>>> + return -ENOMEM; >>>> /* Split original range */ >>>> mem->ranges[i].end = p_start - 1; >>>> temp_range.start = p_end + 1; >>>> @@ -626,9 +629,6 @@ int crash_exclude_mem_range(struct crash_mem *mem, >>>> if (!temp_range.end) >>>> return 0; >>>> - /* Split happened */ >>>> - if (i == mem->max_nr_ranges - 1) >>>> - return -ENOMEM; >>>> /* Location where new range should go */ >>>> j = i + 1; >>>> -- >>>> 2.42.0 >>>> >>>> >>>> _______________________________________________ >>>> kexec mailing list >>>> kexec@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/kexec >>>>