Received: by 2002:a05:7412:8598:b0:f9:33c2:5753 with SMTP id n24csp484682rdh; Tue, 19 Dec 2023 05:09:38 -0800 (PST) X-Google-Smtp-Source: AGHT+IGtBj0bQcGBk5ZwRytpa+cc7t68qRsYO13weu8X+GrtsMKoX1SV9fvL11hjGmf+yvJixNNK X-Received: by 2002:a05:6a20:e11f:b0:194:b0c9:37f8 with SMTP id kr31-20020a056a20e11f00b00194b0c937f8mr659908pzb.105.1702991376051; Tue, 19 Dec 2023 05:09:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702991376; cv=none; d=google.com; s=arc-20160816; b=xjY1vAxneXYFtUKP0LqJqctOX2D7s5WlhqGqq+uiEY/Y+IoMHv3/MdIpojCA7aUIGD 3/FkgCXy7ICTjUKWjPJtkMeZjHyNWGlLeosyKglTY/jelaFt5N097gwfjAHIpFZJzVhf vKqrw19AAR76hn4MtB7JZQzEgYpgWEYH2/py0AO4fJI/B1tZmh6k7UT46+L9RQznmRjM vO58bEAE6wAsH7d3cS+TQ+skLe9ghrT5Y/zsMDf+udBRsscWk1b61N1mHJ3zHVg8ZhOO kVd2+xKCAfOBRXNvvdZ7KXuZoJCkk2O+aQyb/UN+1AK/LD0PaXK1Vp2qcsycq2xtGgVp 9lJg== 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=l847TPb10KXaSUqQZao82w6xGFp9AVSDFxB2wD8NjWI=; fh=HmgEDPidyIWdlj/n2eBdydhqglgkDm0ibYyN4w6vX3I=; b=S+OT+gsyteN1cKe52SnvoVVrzBSDpwoQGK+tIPqhDpzy5zckWt4jHfE2tVGcCNuR+a l4n0PW/tfdd1/269vzD/SQfR9iIkbfvLVkMvHsFPfrcSnlbOoacS/oTzvtPv1z2uEjog K6UnZw/mOyWVNBWEKx8npEyez5433e6YyIGTTzNWgCzE08UNvizspFy7dIWOdhWSurBD XTWWtaxWQ5/4tWnKwMEawreR+RxH4npbeXQy370PgQ+z6mBVg29Djan5xJ1fiUEwvx3M 78ejFZbd4sCXofc+gHJKZ4kZ/a7ogHjmcTg8c6tv8OHvImtgAT7icDhjvVuG96M4QZ9x C15w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-5229-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-5229-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=easystack.cn Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id bt8-20020a056a00438800b006d93b1d9b38si592134pfb.226.2023.12.19.05.09.35 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Dec 2023 05:09:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-5229-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-5229-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-5229-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 sv.mirrors.kernel.org (Postfix) with ESMTPS id 366D9281AD9 for ; Tue, 19 Dec 2023 13:04:39 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6600A1B275; Tue, 19 Dec 2023 13:04:32 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from mail-m25484.xmail.ntesmail.com (mail-m25484.xmail.ntesmail.com [103.129.254.84]) (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 2B9551A71B for ; Tue, 19 Dec 2023 13:04:18 +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.234] (unknown [211.103.144.18]) by smtp.qiye.163.com (Hmail) with ESMTPA id 9ACE5260127; Tue, 19 Dec 2023 20:54:03 +0800 (CST) Message-ID: <273284e8-7680-4f5f-8065-c5d780987e59@easystack.cn> Date: Tue, 19 Dec 2023 20:54:02 +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: Yuntao Wang Cc: bhe@redhat.com, dyoung@redhat.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, vgoyal@redhat.com References: <3765549d-892e-4102-9b56-9add1d0a8089@easystack.cn> <20231219103928.98465-1-ytcoode@gmail.com> From: fuqiang wang In-Reply-To: <20231219103928.98465-1-ytcoode@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFJQjdXWS1ZQUlXWQ8JGhUIEh9ZQVkZQx1JVkwdTxkaGk1NThpNTFUZERMWGhIXJBQOD1 lXWRgSC1lBWUlKSlVKS0hVSk9PVUpDWVdZFhoPEhUdFFlBWU9LSFVKTU9JTE5VSktLVUpCS0tZBg ++ X-HM-Tid: 0a8c8223f70b0276kunm9ace5260127 X-HM-MType: 1 X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6OlE6Nyo5LzE#LwFPAwoqQy0O HzEKCS1VSlVKTEtJQkJLT09OT0tIVTMWGhIXVR0OChIaFRxVDBoVHDseGggCCA8aGBBVGBVFWVdZ EgtZQVlJSkpVSktIVUpPT1VKQ1lXWQgBWUFOS0hMNwY+ 在 2023/12/19 18:39, Yuntao Wang 写道: > On Tue, 19 Dec 2023 16:55:16 +0800, fuqiang wang wrote: > >> Thank you very much for your patient comment. This change does indeed improve >> readability. But as a combination of these two, how do you feel about moving >> crash_setup_memmap_entries() behind vzalloc(). > I don't quite understand what you're trying to express. Hi Yuntao, I make the following changes based on your patch. This change can increase code readability on one hand, On the other hand, if these functions return errors, the rest process of crash_setup_memmap_entries() can be skipped. diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c index c92d88680dbf..67a974c041b9 100644 --- a/arch/x86/kernel/crash.c +++ b/arch/x86/kernel/crash.c @@ -285,6 +285,12 @@ int crash_setup_memmap_entries(struct kimage *image, struct boot_params *params)         cmem = vzalloc(struct_size(cmem, ranges, 1));         if (!cmem)                 return -ENOMEM; +       cmem->max_nr_ranges = 1; + +       /* Exclude some ranges from crashk_res and add rest to memmap */ +       ret = memmap_exclude_ranges(image, cmem, crashk_res.start, crashk_res.end); +       if (ret) +               goto out;         memset(&cmd, 0, sizeof(struct crash_memmap_data));         cmd.params = params; @@ -320,11 +326,6 @@ int crash_setup_memmap_entries(struct kimage *image, struct boot_params *params)                 add_e820_entry(params, &ei);         } -       /* Exclude some ranges from crashk_res and add rest to memmap */ -       ret = memmap_exclude_ranges(image, cmem, crashk_res.start, crashk_res.end); -       if (ret) -               goto out; -         for (i = 0; i < cmem->nr_ranges; i++) {                 ei.size = cmem->ranges[i].end - cmem->ranges[i].start + 1; >> The image->elf_load_addr is determined by arch_kexec_locate_mem_hole(), this >> function can ensure that the value is within the range of [crashk_res.start, >> crashk_res.end), but it seems that it cannot guarantee that its value will >> always be equal to crashk_res.start. Perhaps I have some omissions, please >> point them out. > Because elfcorehdr is the first one and only one that allocates memory from the > starting address of crashk_res, and the starting address of crashk_res meets > the alignment requirement of elfcorehdr. > > elfcorehdr requires 4k alignment, and the starting address of crashk_res is > 16M aligned. > > Therefore, image->elf_load_addr should be equal to crashk_res.start. Yes! you read the code very carefully and I didn't notice that! However, the location of elfheader in crashk_res.start is highly dependent on elfheader in crashk_res memory allocation order and position. At present, x86 first allocate the memory of elfheader. However, ppc64 doesn't seem to be like this (It first executes load_backup_segment()). Although arm64 allocates elfheader first, it sets kbuf.top_down to true in load_other_segments(). This will cause the elfheader to be allocated near crashk_res.end. I debugged using crash on the arm64 machine and the result is(Although the kernel version of the testing machine may be a bit low, the process of allocating elfheaders is consistent with upstream):     crash> p crashk_res.start     $6 = 1375731712     crash> p crashk_res.end     $7 = 2147483647     crash> p kexec_crash_image.arch.elf_headers_mem     $9 = 2147352576 So I think it's best to set cmem->max_nr_ranges to 2 for easy maintenance in the future. What do you think about ?