Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp794676rdb; Fri, 22 Dec 2023 05:29:17 -0800 (PST) X-Google-Smtp-Source: AGHT+IEk6nGjFTg9lMO7oCkmPR8q7I1LXW7BXqTbCOeBFz7SNQWcDPCS6d3EI8+BtLzB3S5SEgUA X-Received: by 2002:a05:6214:1301:b0:67f:1ead:31ab with SMTP id pn1-20020a056214130100b0067f1ead31abmr1386675qvb.107.1703251756806; Fri, 22 Dec 2023 05:29:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703251756; cv=none; d=google.com; s=arc-20160816; b=YOvaSTYYGQz4pd1kw+HHEUN58aGoCE41bNO6G4VglqCbeDI9nyd+VxeQX6n2a18asE M/i+ODueUMhA50qWboJ1HR8q0qPjRzQ7cKFsYq0DSWK7JmSVtbkrjZBYiygt1D+AW07N TzEgJmHE+Xv1hqIw6CrOY5vsi/0nVmUOK4/YqVE/EnZafER3rcUVQgs9Tq7/gzTlz8Zt 7CsTBs704f/mBcbNJiY3/urvEawMZRRfrtibIaPYGOVM7uV6utiFVAhTFQB8sh6/PvaI 660lKscQ60zaKoSTcsegn83iwtfOpqejfB8HW8gWBSTm28wTCsttYoKnLv9Xmq3deQjs +G9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=1AKVs7FXg/jWbWMuTLae6aE+SqB8wGNXZoXLlyCDH7c=; fh=jvjTt7uibnf2eMis2SZPrfWWjD4QySFNd/y3SV02B1k=; b=OpAWOdvNozr2zLsXcRn+lTZpPL1u2uYegDqYxTHs/MeuCzpYZ8MpDCcc3hIUxOrIFi UNucJoyuIQ90oRtZvcyc8dw7jpVgP2HWcBIomAu2+Eiqc1OIjifkyxCCdBTykEwjssDF b6I+TF/awxzSB0gsOFFZG3GJb4TT7P+lell1wxuIlXXt71AxdEbNxrHCHbHYqFWnmUty jWyhzZaUX4ujoeMmv3FQlHjv6U+BEYAl6zuwSssJDcjOTLHiAnn9XAcq4trVDxzvamZ7 GsqehThyvmgwHLHFGZ9xs2NoJzAihiYW8aZgFfNICdJG2lAJpd0PHDLrqztIwkB5Ii/J 7nVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ARrdx0k3; spf=pass (google.com: domain of linux-kernel+bounces-9753-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-9753-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id d10-20020a0cf0ca000000b0067f3c44ed2esi4430869qvl.564.2023.12.22.05.29.16 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Dec 2023 05:29:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-9753-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ARrdx0k3; spf=pass (google.com: domain of linux-kernel+bounces-9753-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-9753-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com 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 90A2C1C21E8D for ; Fri, 22 Dec 2023 13:29:16 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 671C9224C1; Fri, 22 Dec 2023 13:29:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ARrdx0k3" X-Original-To: linux-kernel@vger.kernel.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 1CC1D224D1 for ; Fri, 22 Dec 2023 13:29:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1703251750; 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: in-reply-to:in-reply-to:references:references; bh=1AKVs7FXg/jWbWMuTLae6aE+SqB8wGNXZoXLlyCDH7c=; b=ARrdx0k3d09Ba86oflONlmxgAr9nnasS/uCYvF6RFECeCbABTjowpF3sOzc+d1rM9SAplu a0erlErS3TJMg0TOKXud+JWlFSYnEYY54J//nF942dWZhKnDuUGT0uUnR/5PXpMXJe1XNr pRQofaX8uQhF2oneisrmvRZVWFq+qgU= 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-85-3J-sf6PDOOaljrRLbWYWug-1; Fri, 22 Dec 2023 08:29:06 -0500 X-MC-Unique: 3J-sf6PDOOaljrRLbWYWug-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (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 807558489A8; Fri, 22 Dec 2023 13:29:06 +0000 (UTC) Received: from localhost (unknown [10.72.116.38]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AA44FC15968; Fri, 22 Dec 2023 13:29:04 +0000 (UTC) Date: Fri, 22 Dec 2023 21:29:01 +0800 From: Baoquan He To: fuqiang wang Cc: Vivek Goyal , Dave Young , kexec@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] x86/kexec: fix potential cmem->ranges out of bounds Message-ID: References: <20231222121855.148215-1-fuqiang.wang@easystack.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231222121855.148215-1-fuqiang.wang@easystack.cn> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 On 12/22/23 at 08:18pm, fuqiang wang wrote: > In memmap_exclude_ranges(), there will exclude elfheader from ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ elfheader will be excluded from crashk_res. OR it will exclude elfheader from crashk_res. > crashk_res. In the current x86 architecture code, the elfheader is > always allocated at crashk_res.start. It seems that there won't be a > split a new range. But it depends on the allocation position of ~~~~~~~~~~~~~~~~~~ It seems that there won't be a new split range. > elfheader in crashk_res. To avoid potential out of bounds in future, add > a extra slot. > > The similar issue also exists in fill_up_crash_elf_data(). The range to > be excluded is [0, 1M], start (0) is special and will not appear in the > middle of existing cmem->ranges[]. But in order to lest the low 1M could ~~~~~~~~~~~~~~~~ in case > be changed in the future, add a extra slot too. > > Previously discussed link: > [1] https://lore.kernel.org/kexec/ZXk2oBf%2FT1Ul6o0c@MiWiFi-R3L-srv/ > [2] https://lore.kernel.org/kexec/273284e8-7680-4f5f-8065-c5d780987e59@easystack.cn/ > [3] https://lore.kernel.org/kexec/ZYQ6O%2F57sHAPxTHm@MiWiFi-R3L-srv/ > > Signed-off-by: fuqiang wang > --- > arch/x86/kernel/crash.c | 21 +++++++++++++++++++-- > 1 file changed, 19 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c > index c92d88680dbf..97d33a6fc4fb 100644 > --- a/arch/x86/kernel/crash.c > +++ b/arch/x86/kernel/crash.c > @@ -149,8 +149,18 @@ static struct crash_mem *fill_up_crash_elf_data(void) > /* > * Exclusion of crash region and/or crashk_low_res may cause > * another range split. So add extra two slots here. > + * > + * Exclusion of low 1M may not cause another range split, because the > + * range of exclude is [0, 1M] and the condition for splitting a new > + * region is that the start, end parameters are both in a certain > + * existing region in cmem and cannot be equal to existing region's > + * start or end. Obviously, the start of [0, 1M] cannot meet this > + * condition. > + * > + * But in order to lest the low 1M could be changed in the future, > + * (e.g. [stare, 1M]), add a extra slot. Sometime, too much is as bad as too little. I feel below words are enough to state three regions are gonna be excluded, and may cause another split (may not cause). The code comment plus commit log can help people know why they are needed. * Exclusion of low1M, crashk_res and/or crashk_low_res may cause * another range split. So add extra three slots here. > */ > - nr_ranges += 2; > + nr_ranges += 3; > cmem = vzalloc(struct_size(cmem, ranges, nr_ranges)); > if (!cmem) > return NULL; > @@ -282,9 +292,16 @@ 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)); > + /* > + * In the current x86 architecture code, the elfheader is always > + * allocated at crashk_res.start. But it depends on the allocation > + * position of elfheader in crashk_res. To avoid potential out of > + * bounds in future, add a extra slot. > + */ Ditto. + /* + * Elfheader gonna be excluded from crashk_res, to avoid potential + * out of bounds, add one extra slot. + */ > + cmem = vzalloc(struct_size(cmem, ranges, 2)); > if (!cmem) > return -ENOMEM; > + cmem->max_nr_ranges = 2; > > memset(&cmd, 0, sizeof(struct crash_memmap_data)); > cmd.params = params; > -- > 2.42.0 >