Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp5096317rdb; Tue, 12 Dec 2023 20:44:44 -0800 (PST) X-Google-Smtp-Source: AGHT+IFRRSDTm4PGwdzrcDNGsIqXS57suMnFjIbcTj3jfJyZVwFg6NV7jSIHU5sdUJr8vcDgM7G7 X-Received: by 2002:a05:6871:a50d:b0:1fa:dac9:1cd2 with SMTP id wc13-20020a056871a50d00b001fadac91cd2mr8512502oab.27.1702442683968; Tue, 12 Dec 2023 20:44:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702442683; cv=none; d=google.com; s=arc-20160816; b=MXYsWJBgi9z33LJvhm3QJXK/K8RkPw/XWpn0kkwtZf4GENp7V/t3TE6E1WZWo7Fg6n KqQ0vDfUCbct1jmNUiOI0/nZWoKFe0rULLoymEh8bJaFOSUaUIkFWI0zL7bU1Ef+npmD EbIMgwaDtstmOZihRXclfKEqVftyTTLTD0VmT6HddLTYoPdiWQ7R8AjmUISSTMxR4VdV N46g/KwsICK1mEpfp56/npSFb1J7uuRrEgbdWfM/NhzScPWSU7c/wp6urMgWxAKW8gD+ PYXrMFqZbmgAfp6/A0A7EZy2yjwIg7atjRGEY9J3UtaGFzKDfz0d7wEkKhbGkQGCLcgo 6+zA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=G/cTbycJ6+L1OUYZmWcVqrZarTlp5To90eqHIi055Fw=; fh=jvjTt7uibnf2eMis2SZPrfWWjD4QySFNd/y3SV02B1k=; b=HSXkrH3zWAcziPiB9mDRGizhiDf9YSRkFCChNf+zk3zsNjiykssOnUD5udXIas9l0r bnh9UenVWPOiRR/R8hJvm/scSuU5wEdzN771oedkS3m619tNNdRJjCQ2Xj4ESFyEoSJz 51iYz1iIJWYvAFtZbTSkcVezhwZvyZXwxFvQRIwsw/kHhEGY8Ll29npwvLTlJvv/9TSY oPpBq9jwsUZPZNq+2tLOFGL0VGnUEPiVS7O2oHUj5WpEgdI2Ev7d/zN1Z/UEgkxE96Mk K0EqFSpYjXAbnxftR/asjPWeccL5TrFZo7Sxj7w4v0sFtgXozbnrng/Ti09nZbiLfOrI w2pw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SQWa+zSm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id c15-20020a634e0f000000b005c6075f8a31si8716165pgb.153.2023.12.12.20.44.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Dec 2023 20:44:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SQWa+zSm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 3441B801B322; Tue, 12 Dec 2023 20:44:41 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378486AbjLMEoY (ORCPT + 99 others); Tue, 12 Dec 2023 23:44:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57328 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378466AbjLMEoX (ORCPT ); Tue, 12 Dec 2023 23:44:23 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B748EBE for ; Tue, 12 Dec 2023 20:44:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702442668; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=G/cTbycJ6+L1OUYZmWcVqrZarTlp5To90eqHIi055Fw=; b=SQWa+zSmEN5NQSzSAfoJtJvggwHQzzdnE3cMhM7v3K4Sm/tysv1Zkp8G2yBpJ4HxSUW1mc Z8FfvozCtaUkPQ20rcyzLPkWVYGElR5QDvWNDUQ6tZpC5RwNomni+9owf1AVmVrFqVl8Ft 8E6nrtsSyQnd3EXHsyfqV5tDjmfR018= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-390-EdM98yRTMVyc2x2QONcNOw-1; Tue, 12 Dec 2023 23:44:25 -0500 X-MC-Unique: EdM98yRTMVyc2x2QONcNOw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3040983106D; Wed, 13 Dec 2023 04:44:25 +0000 (UTC) Received: from localhost (unknown [10.72.116.83]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7B40251E3; Wed, 13 Dec 2023 04:44:24 +0000 (UTC) Date: Wed, 13 Dec 2023 12:44:16 +0800 From: Baoquan He To: fuqiang wang Cc: Vivek Goyal , Dave Young , kexec@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] kexec: avoid out of bounds in crash_exclude_mem_range() Message-ID: References: <20231127025641.62210-1-fuqiang.wang@easystack.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Tue, 12 Dec 2023 20:44:41 -0800 (PST) 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 > ??? } > ? } > > 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). Sorry for late reply. I checked the code again, there seems to be cases out of bounds occur very possiblly. We may need to enlarge the cmem array to avoid the risk. In below draft code, we need add another slot to exclude the low 1M area when preparing elfcorehdr. And to exclude the elf header region from crash kernel region, we need create the cmem with 2 slots. With these change, we can absolutely avoid out of bounds occurence. What do you think? diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c index 1715e5f06a59..21facabcf699 100644 --- a/arch/x86/kernel/crash.c +++ b/arch/x86/kernel/crash.c @@ -147,10 +147,10 @@ static struct crash_mem *fill_up_crash_elf_data(void) return NULL; /* - * Exclusion of crash region and/or crashk_low_res may cause - * another range split. So add extra two slots here. + * Exclusion of low 1M, crash region and/or crashk_low_res may + * cause another range split. So add extra two slots here. */ - nr_ranges += 2; + nr_ranges += 3; cmem = vzalloc(struct_size(cmem, ranges, nr_ranges)); if (!cmem) return NULL; @@ -282,7 +282,7 @@ int crash_setup_memmap_entries(struct kimage *image, struct boot_params *params) struct crash_memmap_data cmd; struct crash_mem *cmem; - cmem = vzalloc(struct_size(cmem, ranges, 1)); + cmem = vzalloc(struct_size(cmem, ranges, 2)); if (!cmem) return -ENOMEM;