From nobody Thu Sep 24 20:03:35 2026 Received: from canpmsgout06.his.huawei.com (canpmsgout06.his.huawei.com [113.46.200.221]) (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 515B933A6EB for ; Mon, 21 Sep 2026 09:04:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.221 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981450; cv=none; b=HJYwuXBcpPB+xEzOs7jBhlD7CG68HgYEi0y4HHnqXIuRbyYSWfZKHx565UwJ5sLSw3lwJpTNCOLOqgilDCbfWwheF5fJb6WM68QomYK0G5dc5jaLeFXXIJc10hVkMx5KjXQCMUVg5adgXkbJuM/yxWKKQJTsjE/r+IxKSwVHT4c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981450; c=relaxed/simple; bh=eCFAgTdJH4FSOyRPx5LpoMjibigglhXYQPk4p4gEHF4=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nPG2hVKii6jD8PUcJghkGnuYZdxikIK62Esnao9XaqixFGEOQbf6ZtGbsA7xQg+EkgWnALjefbu8UJ7JBNPIwZ3wwcmW/wFWO4HV65Z5MwgvXEA38caiq6THQ/O7QHiNuylkcIYsdRQzOBAe81xUzJcg+5i3nXGkASCNr8PPULE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=5yDR7210; arc=none smtp.client-ip=113.46.200.221 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="5yDR7210" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=gpQ4A2b+D+By6QZW9O9qxQ5TRwnsaRRG5wXvsN8j1G0=; b=5yDR7210dJfFq/El83BSXaQy/Jd4qrijPdu6t1uJW27ICVE72mId1HUucilMR6cVQd3YNcu7c xJ5//H/5qFgYAEzzu6wOukrEi962MoeeOLcvKCME4ofqLX6PhTa+0b5cozuDLTi8F4toCSxeO1s JMdlwRJnBmcNHALe2SgT2/w= Received: from mail.maildlp.com (unknown [172.19.162.223]) by canpmsgout06.his.huawei.com (SkyGuard) with ESMTPS id 4hpH665BLqzRhQs; Mon, 21 Sep 2026 16:51:58 +0800 (CST) Received: from kwepemk200008.china.huawei.com (unknown [7.202.194.74]) by mail.maildlp.com (Postfix) with ESMTPS id 4738540561; Mon, 21 Sep 2026 17:03:59 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemk200008.china.huawei.com (7.202.194.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 21 Sep 2026 17:03:57 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v6 01/14] kexec: Fix CMA segment address translation with non-zero text_offset Date: Mon, 21 Sep 2026 17:04:37 +0800 Message-ID: <20260921090450.807575-2-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260921090450.807575-1-ruanjinjie@huawei.com> References: <20260921090450.807575-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemk200008.china.huawei.com (7.202.194.74) Content-Type: text/plain; charset="utf-8" kimage_load_cma_segment() and kimage_map_segment() both translate a CMA segment using page_address(cma), which returns the CMA base address. This ignores segment->mem. On arm64, image_load() adds text_offset to segment->mem before the segment is loaded: kernel_segment->mem +=3D text_offset; kernel_segment->memsz -=3D text_offset; image->start =3D kernel_segment->mem; so segment->mem no longer matches the CMA base. The kernel payload is therefore copied to the wrong offset, while image->start points past it, and kexec jumps into the middle of the kernel. kimage_map_segment() has the same problem for any CMA segment whose mem has been moved. Add kimage_cma_vaddr() to translate a boot physical address inside a CMA segment to its virtual address, and use it in both places. Cc: Andrew Morton Cc: Baoquan He Cc: Mike Rapoport Cc: Pasha Tatashin Cc: Pratyush Yadav Cc: Pingfan Liu Cc: Justinien Bouron Cc: Sourabh Jain Cc: Breno Leitao Cc: stable@vger.kernel.org Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation") Signed-off-by: Jinjie Ruan --- kernel/kexec_core.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c index dc770b9a6d05..7f7cb77f0caa 100644 --- a/kernel/kexec_core.c +++ b/kernel/kexec_core.c @@ -738,11 +738,23 @@ static struct page *kimage_alloc_page(struct kimage *= image, return page; } =20 +/* + * Translate a boot physical address inside a CMA segment to a kernel + * virtual address. Architecture loaders may move segment->mem away from + * the CMA base (arm64 adds text_offset), so the offset must be preserved. + */ +static void *kimage_cma_vaddr(struct page *cma, unsigned long mem) +{ + unsigned long cma_base =3D page_to_boot_pfn(cma) << PAGE_SHIFT; + + return page_address(cma) + (mem - cma_base); +} + static int kimage_load_cma_segment(struct kimage *image, int idx) { struct kexec_segment *segment =3D &image->segment[idx]; struct page *cma =3D image->segment_cma[idx]; - char *ptr =3D page_address(cma); + char *ptr =3D kimage_cma_vaddr(cma, segment->mem); size_t ubytes, mbytes; int result =3D 0; unsigned char __user *buf =3D NULL; @@ -965,7 +977,7 @@ void *kimage_map_segment(struct kimage *image, int idx) =20 cma =3D image->segment_cma[idx]; if (cma) - return page_address(cma); + return kimage_cma_vaddr(cma, image->segment[idx].mem); =20 addr =3D image->segment[idx].mem; size =3D image->segment[idx].memsz; --=20 2.34.1 From nobody Thu Sep 24 20:03:35 2026 Received: from canpmsgout02.his.huawei.com (canpmsgout02.his.huawei.com [113.46.200.217]) (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 B249345D90C for ; Mon, 21 Sep 2026 09:04:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.217 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981458; cv=none; b=LJouEStlWnXuUP0k5pR19GDND4wW5J87upFYdUpb0cYwsgXshUPr6KziSl81Qgmt3bC4y1MphT5cWxoYl4qZWpz1ko5s7+qwQkjC8Eh5ovBgkeeyv5BDMBWYAGL52u1rnQqs7id4xyehDBsdGYnn7Jf1fDyWLkwELoTka47hS2M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981458; c=relaxed/simple; bh=WqgZmbSoTjktxY7pxRUGwvCi0FjZW7IsJfvILpjY3D0=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ca4zGHj1Hs14VK4B14uj5a+N8M8FYEv44IjlpQ6RaCJg7wWXy9KqCSp22+47bdsQ1vvSASJuvzoapwtEC7yOv6++38lZhPMwC2wbEuuy0SmsrFnrttBoO08oOjxPOa++8xE3Zmu0Nuf5lFh46jR3BTtI1YpGq1XeR9KnSDSeTVI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=ftprzc4s; arc=none smtp.client-ip=113.46.200.217 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="ftprzc4s" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=exT85uJQjkgif9mGkOjx9OW7SNCVfp7++L6BnEZoSKA=; b=ftprzc4s7QFctL2nl+sgGFpQqjZKPEpbBNWw8vL33PgDLcDsvqh5dBKWq4JOmpUMYJmDb90q6 IJuhC3VJ9RTKizQD1/q1MihCFoIHC1v30oVjT/+WRSf4LOomKTAr4sWIxZAPI3AZyPBfeHEChEO PMPkCDZKcqwLlcsusoXrH9g= Received: from mail.maildlp.com (unknown [172.19.162.140]) by canpmsgout02.his.huawei.com (SkyGuard) with ESMTPS id 4hpH6w3d2Bzcb3G; Mon, 21 Sep 2026 16:52:40 +0800 (CST) Received: from kwepemk200008.china.huawei.com (unknown [7.202.194.74]) by mail.maildlp.com (Postfix) with ESMTPS id 0F951203B8; Mon, 21 Sep 2026 17:04:01 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemk200008.china.huawei.com (7.202.194.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 21 Sep 2026 17:03:59 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v6 02/14] kexec: Record allocated CMA pages to fix release size mismatch Date: Mon, 21 Sep 2026 17:04:38 +0800 Message-ID: <20260921090450.807575-3-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260921090450.807575-1-ruanjinjie@huawei.com> References: <20260921090450.807575-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemk200008.china.huawei.com (7.202.194.74) Content-Type: text/plain; charset="utf-8" The CMA pages allocated for a kexec segment are released using the segment's memsz to calculate the number of pages. However, some architecture loaders modify the segment's memsz after allocation (e.g. arm64 subtracts text_offset), causing the release function to free fewer pages than were originally allocated, leaking the remaining CMA pages. Add a per-segment `segment_cma_pages` array to store the number of pages actually allocated from CMA. Populate it during kexec_add_buffer() using the aligned memsz, and use it in kimage_free_cma() to accurately release all allocated pages. This avoids relying on the potentially modified segment->memsz and prevents silent CMA memory leaks. Cc: Andrew Morton Cc: Baoquan He Cc: Mike Rapoport Cc: Pasha Tatashin Cc: Pratyush Yadav Cc: Brian Mak Cc: Pingfan Liu Cc: Sourabh Jain Cc: Justinien Bouron Cc: Li Chen Cc: Breno Leitao Cc: stable@vger.kernel.org Link: https://sashiko.dev/#/patchset/20260729031235.2840255-1-ruanjinjie%40= huawei.com Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation") Signed-off-by: Jinjie Ruan --- include/linux/kexec.h | 1 + kernel/kexec_core.c | 7 ++++--- kernel/kexec_file.c | 13 +++++++++---- 3 files changed, 14 insertions(+), 7 deletions(-) diff --git a/include/linux/kexec.h b/include/linux/kexec.h index 0af8ae4fdd08..6b1df80524bf 100644 --- a/include/linux/kexec.h +++ b/include/linux/kexec.h @@ -349,6 +349,7 @@ struct kimage { unsigned long nr_segments; struct kexec_segment segment[KEXEC_SEGMENT_MAX]; struct page *segment_cma[KEXEC_SEGMENT_MAX]; + unsigned long segment_cma_pages[KEXEC_SEGMENT_MAX]; =20 struct list_head control_pages; struct list_head dest_pages; diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c index 7f7cb77f0caa..5493591a9e4b 100644 --- a/kernel/kexec_core.c +++ b/kernel/kexec_core.c @@ -560,14 +560,15 @@ static void kimage_free_cma(struct kimage *image) =20 for (i =3D 0; i < image->nr_segments; i++) { struct page *cma =3D image->segment_cma[i]; - u32 nr_pages =3D image->segment[i].memsz >> PAGE_SHIFT; + unsigned long nr_pages =3D image->segment_cma_pages[i]; =20 if (!cma) continue; =20 - arch_kexec_pre_free_pages(page_address(cma), nr_pages); - dma_release_from_contiguous(NULL, cma, nr_pages); + arch_kexec_pre_free_pages(page_address(cma), (unsigned int)nr_pages); + dma_release_from_contiguous(NULL, cma, (int)nr_pages); image->segment_cma[i] =3D NULL; + image->segment_cma_pages[i] =3D 0; } =20 } diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c index 59fb9d71e9d8..67d6df9824e6 100644 --- a/kernel/kexec_file.c +++ b/kernel/kexec_file.c @@ -670,7 +670,7 @@ static int kexec_walk_resources(struct kexec_buf *kbuf, =20 static int kexec_alloc_contig(struct kexec_buf *kbuf) { - size_t nr_pages =3D kbuf->memsz >> PAGE_SHIFT; + size_t nr_pages =3D PFN_DOWN(kbuf->memsz); unsigned long mem; struct page *p; =20 @@ -756,14 +756,16 @@ int kexec_locate_mem_hole(struct kexec_buf *kbuf) */ int kexec_add_buffer(struct kexec_buf *kbuf) { + unsigned long nr_segments =3D kbuf->image->nr_segments; struct kexec_segment *ksegment; + size_t nr_cma_pages =3D 0; int ret; =20 /* Currently adding segment this way is allowed only in file mode */ if (!kbuf->image->file_mode) return -EINVAL; =20 - if (kbuf->image->nr_segments >=3D KEXEC_SEGMENT_MAX) + if (nr_segments >=3D KEXEC_SEGMENT_MAX) return -EINVAL; =20 /* @@ -789,12 +791,15 @@ int kexec_add_buffer(struct kexec_buf *kbuf) return ret; =20 /* Found a suitable memory range */ - ksegment =3D &kbuf->image->segment[kbuf->image->nr_segments]; + ksegment =3D &kbuf->image->segment[nr_segments]; ksegment->kbuf =3D kbuf->buffer; ksegment->bufsz =3D kbuf->bufsz; ksegment->mem =3D kbuf->mem; ksegment->memsz =3D kbuf->memsz; - kbuf->image->segment_cma[kbuf->image->nr_segments] =3D kbuf->cma; + kbuf->image->segment_cma[nr_segments] =3D kbuf->cma; + if (kbuf->cma) + nr_cma_pages =3D PFN_DOWN(kbuf->memsz); + kbuf->image->segment_cma_pages[nr_segments] =3D nr_cma_pages; kbuf->image->nr_segments++; return 0; } --=20 2.34.1 From nobody Thu Sep 24 20:03:35 2026 Received: from canpmsgout04.his.huawei.com (canpmsgout04.his.huawei.com [113.46.200.219]) (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 859BC136351 for ; Mon, 21 Sep 2026 09:04:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.219 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981450; cv=none; b=fKdkxhOpZKcskXXq1oGx0EqGbtKsg6myKzEqlhRR1cfiFO/NtyXVmezFAsNl4OWgVPNijVQeMuh+myuqZWzFFoAByQ5Cb3mWM8nzy58Vh3ahX5tKFU18mnEFSkNxOlcvaiUITgVd8WMr2AmEnNaormBJikXk5ozxEy2BCJkotZI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981450; c=relaxed/simple; bh=kaZLRS3vs4oGde4u4yQtVgrILMKc4P0W3qlKn1W+ewM=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=l81CY62EbRkXfh8j1/A/yfhXX6JB4fsRv9vUgE7WZooVRKH8U3GsmuFpwWus3BHmxilaWpBvG8PeYnOa0WMyTw1yGTM75MLp7JHyeZWuLVLPygi/dks0A/mW9qPGUwnEIBy4+maIqjnl9Cyd0d6s9jvVwJymJzEyaFBzTLq9Btc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=pbi6s2T9; arc=none smtp.client-ip=113.46.200.219 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="pbi6s2T9" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=B+70TPDD35nexD8E4QoPE3SOYsXBOKYnCVcHssGZ2ag=; b=pbi6s2T9Am2gqC06IbJsrFr/pvE3E9XWw6VsBqhZOOS3LOhAstM0zNEtS0NaTRhOIQ6WKpZY7 7RxfvMA9w4AF4qW8ExOGe9tqlcNRsWv0AW5+OGhlZ3SG8ulDOQc0BHTfJ0Ipv6rtIXFqn8lrp8Y OIBJWCGhq/wAj67/fU1BpNY= Received: from mail.maildlp.com (unknown [172.19.163.104]) by canpmsgout04.his.huawei.com (SkyGuard) with ESMTPS id 4hpH7H5fWpz1prpK; Mon, 21 Sep 2026 16:52:59 +0800 (CST) Received: from kwepemk200008.china.huawei.com (unknown [7.202.194.74]) by mail.maildlp.com (Postfix) with ESMTPS id CD4EF4057F; Mon, 21 Sep 2026 17:04:02 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemk200008.china.huawei.com (7.202.194.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 21 Sep 2026 17:04:00 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v6 03/14] kexec: Extract kexec_free_segment_cma() from kimage_free_cma() Date: Mon, 21 Sep 2026 17:04:39 +0800 Message-ID: <20260921090450.807575-4-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260921090450.807575-1-ruanjinjie@huawei.com> References: <20260921090450.807575-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemk200008.china.huawei.com (7.202.194.74) Content-Type: text/plain; charset="utf-8" kimage_free_cma() relies on image->nr_segments to iterate over segments. When an architecture loader (e.g., arm64) truncates nr_segments on a mid-way failure, CMA pages allocated beyond the new boundary become unreachable, causing silent memory leaks. Extract the per-segment freeing logic into the exported helper kexec_free_segment_cma(), so that architecture loaders can release individual segments before nr_segments is truncated. Refactor kimage_free_cma() to loop over the new helper, preserving existing behavior. Cc: Andrew Morton Cc: Baoquan He Cc: Mike Rapoport Cc: Pasha Tatashin Cc: Pratyush Yadav Cc: Breno Leitao Signed-off-by: Jinjie Ruan --- include/linux/kexec.h | 2 ++ kernel/kexec_core.c | 27 +++++++++++++++------------ 2 files changed, 17 insertions(+), 12 deletions(-) diff --git a/include/linux/kexec.h b/include/linux/kexec.h index 6b1df80524bf..72258d813301 100644 --- a/include/linux/kexec.h +++ b/include/linux/kexec.h @@ -533,6 +533,7 @@ extern bool kexec_file_dbg_print; =20 extern void *kimage_map_segment(struct kimage *image, int idx); extern void kimage_unmap_segment(void *buffer); +void kexec_free_segment_cma(struct kimage *image, unsigned long idx); #else /* !CONFIG_KEXEC_CORE */ struct pt_regs; struct task_struct; @@ -544,6 +545,7 @@ static inline int kexec_crash_loaded(void) { return 0; } static inline void *kimage_map_segment(struct kimage *image, int idx) { return NULL; } static inline void kimage_unmap_segment(void *buffer) { } +static inline void kexec_free_segment_cma(struct kimage *image, unsigned l= ong idx) { } #define kexec_in_progress false #endif /* CONFIG_KEXEC_CORE */ =20 diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c index 5493591a9e4b..31c8228318a7 100644 --- a/kernel/kexec_core.c +++ b/kernel/kexec_core.c @@ -554,23 +554,26 @@ static void kimage_free_entry(kimage_entry_t entry) kimage_free_pages(page); } =20 -static void kimage_free_cma(struct kimage *image) +void kexec_free_segment_cma(struct kimage *image, unsigned long idx) { - unsigned long i; + unsigned long nr_pages =3D image->segment_cma_pages[idx]; + struct page *cma =3D image->segment_cma[idx]; =20 - for (i =3D 0; i < image->nr_segments; i++) { - struct page *cma =3D image->segment_cma[i]; - unsigned long nr_pages =3D image->segment_cma_pages[i]; + if (!cma) + return; =20 - if (!cma) - continue; + arch_kexec_pre_free_pages(page_address(cma), (unsigned int)nr_pages); + dma_release_from_contiguous(NULL, cma, (int)nr_pages); + image->segment_cma[idx] =3D NULL; + image->segment_cma_pages[idx] =3D 0; +} =20 - arch_kexec_pre_free_pages(page_address(cma), (unsigned int)nr_pages); - dma_release_from_contiguous(NULL, cma, (int)nr_pages); - image->segment_cma[i] =3D NULL; - image->segment_cma_pages[i] =3D 0; - } +static void kimage_free_cma(struct kimage *image) +{ + unsigned long i; =20 + for (i =3D 0; i < image->nr_segments; i++) + kexec_free_segment_cma(image, i); } =20 void kimage_free(struct kimage *image) --=20 2.34.1 From nobody Thu Sep 24 20:03:35 2026 Received: from canpmsgout02.his.huawei.com (canpmsgout02.his.huawei.com [113.46.200.217]) (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 8B98645FFC2 for ; Mon, 21 Sep 2026 09:04:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.217 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981457; cv=none; b=CW08nT5veX8VeQjQpzidAwTaSWMRoNjTie5p1P2VMxtAULN5oEE2UAvZ8RPSQkaRd30adbNfulWsH2p5ObzorJuR5rFiLWArQXYALEMVs8Srv0b0tEW2l6gGM6iw3DVW/OAWuBsiAxDEdJBoFQcz/z9umXfJZTenP8llPLTnLh0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981457; c=relaxed/simple; bh=dwgncQqVyzPFNessPOGKN2UeVG9vVedPe+OsTFQgmXU=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=aUL5E2sOxowQqvwJOjgHvU3NDphEM8ZLWn5bvU/dg/T/jDaPT8qZH7ZCbxtFmxTcD8WLL5CaRRA1q+AbVS2XIoocEMnZedx+91zLgoc02H8GZjTzwA//VMpU9RMk3qBUiQ0SPr8ngFAv+9D6nE03GAOKPD3PI5h9XoKas8AWkzE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=CtxVcq19; arc=none smtp.client-ip=113.46.200.217 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="CtxVcq19" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=igqtNYMEL8oKIpnu2DrMNvEYzwwJSEovzlP+FnYUOCA=; b=CtxVcq19s4/+nlwp4cUNXfDx1nZiyIWFU4uWCub+//6KtP7pZWS9arcnPlF2LC/ogoKXyeVeP TCuE1W141iovkLTXAPEBXvujBx6CaVYA0od9WENgqjGwUbcGu+QPm1w6sqo05U8KePvOSjI314O 40wUQWbWiVj05nmSEjphxXc= Received: from mail.maildlp.com (unknown [172.19.162.144]) by canpmsgout02.his.huawei.com (SkyGuard) with ESMTPS id 4hpH70064kzcb3H; Mon, 21 Sep 2026 16:52:44 +0800 (CST) Received: from kwepemk200008.china.huawei.com (unknown [7.202.194.74]) by mail.maildlp.com (Postfix) with ESMTPS id 8D0254056D; Mon, 21 Sep 2026 17:04:04 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemk200008.china.huawei.com (7.202.194.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 21 Sep 2026 17:04:02 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v6 04/14] arm64: kexec_file: Fix CMA page leaks in segment placement retry loops Date: Mon, 21 Sep 2026 17:04:40 +0800 Message-ID: <20260921090450.807575-5-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260921090450.807575-1-ruanjinjie@huawei.com> References: <20260921090450.807575-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemk200008.china.huawei.com (7.202.194.74) Content-Type: text/plain; charset="utf-8" During kexec image placement retry loops, any midway failure causes the loader to truncate `image->nr_segments` back to its initial state to purge the failed segments. However, this truncation introduces a memory leak. The CMA pages allocated via kexec_add_buffer() during the failed attempt are tracked in the `image->segment_cma` array. Because the subsequent cleanup paths only iterate up to the truncated `nr_segments` boundary, these allocated CMA pages outside the new boundary are permanently leaked. Fix this by explicitly releasing the associated CMA buffers in the failure paths before `image->nr_segments` is reduced. Cc: Catalin Marinas Cc: Will Deacon Cc: Breno Leitao Cc: Pratyush Yadav Cc: Andrew Morton Cc: Yeoreum Yun Cc: Baoquan He Cc: stable@vger.kernel.org Fixes: 07d24902977e4 ("kexec: enable CMA based contiguous allocation") Signed-off-by: Jinjie Ruan --- arch/arm64/kernel/kexec_image.c | 1 + arch/arm64/kernel/machine_kexec_file.c | 5 ++++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_imag= e.c index b70f4df15a1a..ffcb7f9075e6 100644 --- a/arch/arm64/kernel/kexec_image.c +++ b/arch/arm64/kernel/kexec_image.c @@ -107,6 +107,7 @@ static void *image_load(struct kimage *image, * We couldn't find space for the other segments; erase the * kernel segment and try the next available hole. */ + kexec_free_segment_cma(image, kernel_segment_number); image->nr_segments -=3D 1; kbuf.buf_min =3D kernel_segment->mem + kernel_segment->memsz; kbuf.mem =3D KEXEC_BUF_MEM_UNKNOWN; diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/mac= hine_kexec_file.c index 854d872dfd0f..e48f29167b38 100644 --- a/arch/arm64/kernel/machine_kexec_file.c +++ b/arch/arm64/kernel/machine_kexec_file.c @@ -179,7 +179,10 @@ int load_other_segments(struct kimage *image, return 0; =20 out_err: - image->nr_segments =3D orig_segments; + while (image->nr_segments > orig_segments) { + kexec_free_segment_cma(image, image->nr_segments - 1); + image->nr_segments--; + } kvfree(dtb); return ret; } --=20 2.34.1 From nobody Thu Sep 24 20:03:35 2026 Received: from canpmsgout08.his.huawei.com (canpmsgout08.his.huawei.com [113.46.200.223]) (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 8753837AA95 for ; Mon, 21 Sep 2026 09:04:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.223 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981452; cv=none; b=f97qX/LO4nUW8shI1OKqZFKsXpppU6iqGfKx3lWNbuPhR9XpVY7evZm/M7Pd1yuRRV1LVWjJG5YwSnDXq42sGWNGGLPOGK+Gn9A3voAbgEexX2vWvczEMmyNJNoKaZlLUsGndbh80DQnVPZjzO1OabUDAugHEGiqD55lB4HycQM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981452; c=relaxed/simple; bh=yiGxQ7QIQdwQ3p4Fr0ygdVNI7N08QTdXriOuGM/62Gk=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=b8uHDW6XqLYVBWXntisocfeAmQyN+RfpW+LH8oQ3Z+dzYclhMLxCMA5dK7tD8sdkBdYgmy4XTkjuADd+n96TcIMmj4cKx0mf2dSPSzMXGaupU0KdKsIalgDV4QhAh+ubJGzwWxviqYGjnkhJOe8q8bOo+6FfMVPS2rQeG6H/WyU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=cXqqzSbx; arc=none smtp.client-ip=113.46.200.223 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="cXqqzSbx" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=RK4VHRefALxjC8rB7K7w3VAwG6W6KlTC58IWMIYwUgI=; b=cXqqzSbxz3lvEuOS9efT6kFVnZWykzECj9tiFIF8xUH5zySw0l0wtrrPJavS5/6c0ugtHU44w TQx608nHzqqoqjifoGQQm3bSkj4dVZdXvljaZRoir8tVoNs8JWQj9Dkf8ZWXUzNH3gtlFlTVTbj f2PJ9QOpTcwTuI1J8MwWSoI= Received: from mail.maildlp.com (unknown [172.19.163.200]) by canpmsgout08.his.huawei.com (SkyGuard) with ESMTPS id 4hpH7N3HYzzmVY2; Mon, 21 Sep 2026 16:53:04 +0800 (CST) Received: from kwepemk200008.china.huawei.com (unknown [7.202.194.74]) by mail.maildlp.com (Postfix) with ESMTPS id 5E4524055B; Mon, 21 Sep 2026 17:04:06 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemk200008.china.huawei.com (7.202.194.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 21 Sep 2026 17:04:04 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v6 05/14] arm64: kexec_file: Fix elf_headers memory leak in retry loop Date: Mon, 21 Sep 2026 17:04:41 +0800 Message-ID: <20260921090450.807575-6-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260921090450.807575-1-ruanjinjie@huawei.com> References: <20260921090450.807575-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemk200008.china.huawei.com (7.202.194.74) Content-Type: text/plain; charset="utf-8" If load_other_segments() fails after image->elf_headers is assigned, the memory lifecycle is safely managed by the global kimage object and will be freed in arch_kimage_file_post_load_cleanup(). However, during a retry loop in image_load(), a subsequent iteration will allocate a new buffer and overwrite image->elf_headers. This permanently leaks the stale memory from the previous iteration before the global cleanup can track it. Fix this by explicitly freeing the stale `image->elf_headers` buffer before assigning the newly allocated headers. Cc: Catalin Marinas Cc: Will Deacon Cc: Thomas Huth Cc: Breno Leitao Cc: Andrew Morton Cc: Yeoreum Yun Cc: Baoquan He Cc: stable@vger.kernel.org Fixes: 108aa503657e ("arm64: kexec_file: try more regions if loading segmen= ts fails") Signed-off-by: Jinjie Ruan --- arch/arm64/kernel/machine_kexec_file.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/mac= hine_kexec_file.c index e48f29167b38..2f750e5f4fcc 100644 --- a/arch/arm64/kernel/machine_kexec_file.c +++ b/arch/arm64/kernel/machine_kexec_file.c @@ -112,6 +112,10 @@ int load_other_segments(struct kimage *image, vfree(headers); goto out_err; } + + if (unlikely(image->elf_headers)) + vfree(image->elf_headers); + image->elf_headers =3D headers; image->elf_load_addr =3D kbuf.mem; image->elf_headers_sz =3D headers_sz; --=20 2.34.1 From nobody Thu Sep 24 20:03:35 2026 Received: from canpmsgout08.his.huawei.com (canpmsgout08.his.huawei.com [113.46.200.223]) (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 F168E45DF69 for ; Mon, 21 Sep 2026 09:04:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.223 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981458; cv=none; b=i2Sxg3IhAjeOENNS2O9rtT7d2kTlrrdS2WZiwJP0dRWARTOM6LeSUeNRC0Ht/VCtjD0S5WoCVx9RaJY4xQiyqauBEwmYtcNyjuvFzotanxT7THrdHMcXqdzB88/KIZbDgfvhZ2aI75iu2tXB6jggjAsQeXJ55pbGkjLPPyE6ff8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981458; c=relaxed/simple; bh=pqwmROV2ldLwW0tL4b4mcAsvlFNFi2XdYsiPH9Ty7ls=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ebp1ryX8UrTn4SA+HKI0/Ex+15ITpJTth/BQXxnucwdVXln3DP02MrRSY7GayEXVLbH+q68dZTSAwr7EN2OvpRbSQ85EQStDyyx2v4QXWoco/R1NSGEQ6rNp1TjDYoU5F9UPS/ixpDFiN69H0CVhJfcHA0r3X/xU7TsCReKlw/4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=xq1YbTvD; arc=none smtp.client-ip=113.46.200.223 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="xq1YbTvD" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=C/N27OffVwB9HknmerMZN+vGpNQOngX4+yhYYxhlpgs=; b=xq1YbTvD3XNNnXqFEYm+rNDxG6EdsqcQH0HTMN1s5TayGIm1XkNSyQvmkbCWJmLw2RC3Hg9MW 03OTT0taTlXRmwul+dn+StNpv/it+wBQ3leQZDkbShT3eaE7XAglReIYtuKqLTKOKW4s7jvAaSh i66n7enwbsFGUXQhFmGkLKQ= Received: from mail.maildlp.com (unknown [172.19.163.15]) by canpmsgout08.his.huawei.com (SkyGuard) with ESMTPS id 4hpH7Q1fbDzmV8f; Mon, 21 Sep 2026 16:53:06 +0800 (CST) Received: from kwepemk200008.china.huawei.com (unknown [7.202.194.74]) by mail.maildlp.com (Postfix) with ESMTPS id 212A040586; Mon, 21 Sep 2026 17:04:08 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemk200008.china.huawei.com (7.202.194.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 21 Sep 2026 17:04:06 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v6 06/14] LoongArch: kexec_file: Fix CMA page leaks in segment placement retry loops Date: Mon, 21 Sep 2026 17:04:42 +0800 Message-ID: <20260921090450.807575-7-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260921090450.807575-1-ruanjinjie@huawei.com> References: <20260921090450.807575-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemk200008.china.huawei.com (7.202.194.74) Content-Type: text/plain; charset="utf-8" During kexec image placement retry loops, any midway failure causes the loader to truncate `image->nr_segments` back to its initial state to purge the failed segments. However, this truncation introduces a memory leak. The CMA pages allocated via kexec_add_buffer() during the failed attempt are tracked in the `image->segment_cma` array. Because the subsequent cleanup paths only iterate up to the truncated `nr_segments` boundary, these allocated CMA pages outside the new boundary are permanently leaked. Fix this by explicitly releasing the associated CMA buffers in the failure paths before `image->nr_segments` is reduced. Cc: Huacai Chen Cc: WANG Xuerui Cc: Youling Tang Cc: "Mike Rapoport (Microsoft)" Cc: Sourabh Jain Cc: Kees Cook Cc: stable@vger.kernel.org Link: https://sashiko.dev/#/patchset/20260729031235.2840255-1-ruanjinjie%40= huawei.com Fixes: 55d990f0084c ("LoongArch: Add EFI binary support for kexec_file") Signed-off-by: Jinjie Ruan --- arch/loongarch/kernel/kexec_efi.c | 1 + arch/loongarch/kernel/machine_kexec_file.c | 6 +++++- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/loongarch/kernel/kexec_efi.c b/arch/loongarch/kernel/kexe= c_efi.c index 5ee78ebb1546..15fd797ff3de 100644 --- a/arch/loongarch/kernel/kexec_efi.c +++ b/arch/loongarch/kernel/kexec_efi.c @@ -86,6 +86,7 @@ static void *efi_kexec_load(struct kimage *image, * We couldn't find space for the other segments; erase the * kernel segment and try the next available hole. */ + kexec_free_segment_cma(image, kernel_segment_number); image->nr_segments -=3D 1; kbuf.buf_min =3D kernel_segment->mem + kernel_segment->memsz; kbuf.mem =3D KEXEC_BUF_MEM_UNKNOWN; diff --git a/arch/loongarch/kernel/machine_kexec_file.c b/arch/loongarch/ke= rnel/machine_kexec_file.c index 5412aa9f3568..62a5be102065 100644 --- a/arch/loongarch/kernel/machine_kexec_file.c +++ b/arch/loongarch/kernel/machine_kexec_file.c @@ -217,7 +217,11 @@ int load_other_segments(struct kimage *image, return 0; =20 out_err: - image->nr_segments =3D orig_segments; + while (image->nr_segments > orig_segments) { + kexec_free_segment_cma(image, image->nr_segments - 1); + image->nr_segments--; + } + kfree(modified_cmdline); return ret; } --=20 2.34.1 From nobody Thu Sep 24 20:03:35 2026 Received: from canpmsgout09.his.huawei.com (canpmsgout09.his.huawei.com [113.46.200.224]) (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 CFBBA466B44 for ; Mon, 21 Sep 2026 09:04:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.224 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981463; cv=none; b=k7NJhgY6pldwoVWNNBNS9KRi0f6vFvdzrKMdV06tnJJNqC5PAUfCwM6q3PllSrtwdJm7+1fxfshaOC2W9mrEZYxXzxhgJSOP4tJ8N+Qw1ug6aS3UkvsRLM2Y3pnvcN4lHTh7ickYkxKB3LFA7FsOAjKSztJ+7BcY6U7lCfKUofk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981463; c=relaxed/simple; bh=LUUN6hor9kB1vGW9ORLacT7hasUnGUVa0oXa/BtcYiM=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=m8+jh1hbXa8SgGRq7g8Am5H/Y4HltU1DDUJ2j+gwpOJeeNHWNTa03S1qxWGq4n6lj0MK4EnikJEM3L1eZ70A5DWSQZAdp4mbtQpuX5jPgWF2VEPqkW+gplBPrwYoKt0uILD68QD10eWkOsSjVNpnBPqAY1VazH3qKDDbUmyTK5U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=WJsU5ZLP; arc=none smtp.client-ip=113.46.200.224 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="WJsU5ZLP" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=up4/oktyfAdON3km3wdZWwjp1/r+vQu8s3QiiQB06UU=; b=WJsU5ZLPqqnObamEl+eDb1OQLn8fzTm2lS+jqZvsjkBOcZoPNvOCq137VskBlGKfkXIRHLxz0 r3TIwLJgnYKX+hhXcyhYsMrcfZw4l3uKg5x5sTenzOpFogQlp8Dx4ywI3SARgUR1LDQ5r9Wjz1F GJzxQD5oYk6LTh2w3OIGcw8= Received: from mail.maildlp.com (unknown [172.19.163.214]) by canpmsgout09.his.huawei.com (SkyGuard) with ESMTPS id 4hpH7S5vyBz1cyVy; Mon, 21 Sep 2026 16:53:08 +0800 (CST) Received: from kwepemk200008.china.huawei.com (unknown [7.202.194.74]) by mail.maildlp.com (Postfix) with ESMTPS id E3ED14056C; Mon, 21 Sep 2026 17:04:09 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemk200008.china.huawei.com (7.202.194.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 21 Sep 2026 17:04:07 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v6 07/14] LoongArch: kexec_file: Fix elf_headers memory leak in retry loop Date: Mon, 21 Sep 2026 17:04:43 +0800 Message-ID: <20260921090450.807575-8-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260921090450.807575-1-ruanjinjie@huawei.com> References: <20260921090450.807575-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemk200008.china.huawei.com (7.202.194.74) Content-Type: text/plain; charset="utf-8" If load_other_segments() fails after image->elf_headers is assigned, the memory lifecycle is safely managed by the global kimage object and will be freed in arch_kimage_file_post_load_cleanup(). However, during a retry loop in efi_kexec_load(), a subsequent iteration will allocate a new buffer and overwrite image->elf_headers. This permanently leaks the stale memory from the previous iteration before the global cleanup can track it. Fix this by explicitly freeing the stale `image->elf_headers` buffer before assigning the newly allocated headers. Cc: Huacai Chen Cc: WANG Xuerui Cc: Youling Tang Cc: "Mike Rapoport (Microsoft)" Cc: Sourabh Jain Cc: Kees Cook Cc: stable@vger.kernel.org Link: https://sashiko.dev/#/patchset/20260729031235.2840255-1-ruanjinjie%40= huawei.com Fixes: 55d990f0084c ("LoongArch: Add EFI binary support for kexec_file") Signed-off-by: Jinjie Ruan --- arch/loongarch/kernel/machine_kexec_file.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/loongarch/kernel/machine_kexec_file.c b/arch/loongarch/ke= rnel/machine_kexec_file.c index 62a5be102065..3beb6977ecc6 100644 --- a/arch/loongarch/kernel/machine_kexec_file.c +++ b/arch/loongarch/kernel/machine_kexec_file.c @@ -166,6 +166,10 @@ int load_other_segments(struct kimage *image, vfree(headers); goto out_err; } + + if (unlikely(image->elf_headers)) + vfree(image->elf_headers); + image->elf_headers =3D headers; image->elf_load_addr =3D kbuf.mem; image->elf_headers_sz =3D headers_sz; --=20 2.34.1 From nobody Thu Sep 24 20:03:35 2026 Received: from canpmsgout03.his.huawei.com (canpmsgout03.his.huawei.com [113.46.200.218]) (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 C268A45FFAE for ; Mon, 21 Sep 2026 09:04:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.218 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981461; cv=none; b=Gz3SZR9On32vOuktx+nkXL301JK+jmS3/xrBlrnhhrGx9TDJOKXqEm6t674XgrIZKvhThefS2NF8QZy3ILeSXTyemSRxauctXl7TFF7bpUQqsh8xAjqQ7SyJ2xm9RqNhAf8kYY6wHs2IwbUhOJ5tC3WNbae3BWpNmZmW+z7HadQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981461; c=relaxed/simple; bh=Ygfamq+zVCgcwFeC3h6mtl26Diwqy0m0fQ1dYnRCot0=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=OuGWqv8HRIfPzfrQHtJivgWWJL+9u+6E1P+jnVCvt0hPFqylK2C59Q5eGyXae8vI2+n0SnS3SIndgWoIq1FYwlozecbMQ5a6R5XeEdp3istqKNgFE/OLp/nHc2h/KhKgTONM57hJRODBXPQFYZlu6945BurKoFJCyyQaPvV4Z6A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=h20MzYgr; arc=none smtp.client-ip=113.46.200.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="h20MzYgr" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=20ZJiQbk77XpGyt2zLlFzhTV8L6cgd0AT+Mg72ZNP+o=; b=h20MzYgrtfLEEV4IsF22m8M0aeU+9fIDiLpJWraCVTgEvlTBvhYu0irkyY7dZ8KlR25j3eFDX uDHiuEi34Vyc2FyCL6c39JSfjX+M3Cz00j/vkUz1PTc66H//7kIYPJQEJrTEE3IZKzXvZCqcFXg laCNtc/NvKopW2lnm4CTtD4= Received: from mail.maildlp.com (unknown [172.19.163.104]) by canpmsgout03.his.huawei.com (SkyGuard) with ESMTPS id 4hpH6T2gsnzpStW; Mon, 21 Sep 2026 16:52:17 +0800 (CST) Received: from kwepemk200008.china.huawei.com (unknown [7.202.194.74]) by mail.maildlp.com (Postfix) with ESMTPS id B60454058E; Mon, 21 Sep 2026 17:04:11 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemk200008.china.huawei.com (7.202.194.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 21 Sep 2026 17:04:09 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v6 08/14] LoongArch: kexec_file: Fix a modified_cmdline leak Date: Mon, 21 Sep 2026 17:04:44 +0800 Message-ID: <20260921090450.807575-9-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260921090450.807575-1-ruanjinjie@huawei.com> References: <20260921090450.807575-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemk200008.china.huawei.com (7.202.194.74) Content-Type: text/plain; charset="utf-8" load_other_segments() allocates modified_cmdline and stores it in image->arch.cmdline_ptr. machine_kexec_prepare() then copies it to KEXEC_CMDLINE_ADDR and overwrites the pointer, so the heap buffer is leaked on every successful kexec_file_load(). Free the buffer after the copy. Cc: Huacai Chen Cc: WANG Xuerui Cc: Kexin Liu Cc: Youling Tang Cc: Qiang Ma Cc: Tianyang Zhang Cc: George Guo Cc: stable@vger.kernel.org Fixes: d162feec6b6e ("LoongArch: Add preparatory infrastructure for kexec_f= ile") Signed-off-by: Jinjie Ruan --- arch/loongarch/kernel/machine_kexec.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/loongarch/kernel/machine_kexec.c b/arch/loongarch/kernel/= machine_kexec.c index 1883cae93bc3..19ccc91b6f2a 100644 --- a/arch/loongarch/kernel/machine_kexec.c +++ b/arch/loongarch/kernel/machine_kexec.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include =20 @@ -56,6 +57,7 @@ int machine_kexec_prepare(struct kimage *kimage) */ memcpy((void *)KEXEC_CMDLINE_ADDR, (void *)kimage->arch.cmdline_ptr, strlen((char *)kimage->arch.cmdline_ptr) + 1); + kfree((void *)kimage->arch.cmdline_ptr); kimage->arch.cmdline_ptr =3D (unsigned long)KEXEC_CMDLINE_ADDR; } else { /* Find the command line */ --=20 2.34.1 From nobody Thu Sep 24 20:03:35 2026 Received: from canpmsgout06.his.huawei.com (canpmsgout06.his.huawei.com [113.46.200.221]) (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 B06AF469823 for ; Mon, 21 Sep 2026 09:04:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.221 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981464; cv=none; b=recmK/iemfFCty3wRdOfBYBYhSQCIZuzA5Tk5YsD76xxTrcObun1daGEhjVSScPodEPi7gDwC2yivRC6RUOkQw/bmXHznHVUdCMNXNxjKFDD1oi3c01c6Dt5DUWsqGLLsg5ctRaXGAXL7pOdrV/RmmCDzHR6ZfLxZWNlFvE9nC8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981464; c=relaxed/simple; bh=wjR21x1VZ0jBGYVQvbCGyafKMjtbiu05vUZUySil/VY=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=pOxy+Aqef8cG3gRYZtE0kGNu06EjXBbZrbbeqFRez2D3GR6j2l5qiKTp41jizSzRCMCFy7Ghefd2t6Z5sxV+HtChUxaNhm2VqbsUvKEIkgWjiuXhRl1x4mtjAi2T0JfJ2TtgUFeqGyIBQOHDvgfIvgLRptKC+IKHhDV5MAnmEqQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=wVs/Hs9G; arc=none smtp.client-ip=113.46.200.221 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="wVs/Hs9G" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=gl9dOVAVG56ScS9MwUOL4momh5UtqrFy6pN1ShFcuZM=; b=wVs/Hs9Gq6VG/cWAMpWvzJmy/oIAMsdmFRrHLaMN8dhT/208NNm+Jy57C8JdLMxP37J0PUlpB GvTnqbaNF3Y1buLGfFQc0tAbMgmC9XUKdLppSMLKPgLCRodGAQm9QZNfIEVZADGVfpSUfrMTgAo 355Yjh2Bx4bZrE0WgEv0YQ0= Received: from mail.maildlp.com (unknown [172.19.162.140]) by canpmsgout06.his.huawei.com (SkyGuard) with ESMTPS id 4hpH6N5yyJzRhjW; Mon, 21 Sep 2026 16:52:12 +0800 (CST) Received: from kwepemk200008.china.huawei.com (unknown [7.202.194.74]) by mail.maildlp.com (Postfix) with ESMTPS id 7F7142011D; Mon, 21 Sep 2026 17:04:13 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemk200008.china.huawei.com (7.202.194.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 21 Sep 2026 17:04:11 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v6 09/14] x86/crash: Fix massive out-of-bounds write on 32-bit Highmem Date: Mon, 21 Sep 2026 17:04:45 +0800 Message-ID: <20260921090450.807575-10-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260921090450.807575-1-ruanjinjie@huawei.com> References: <20260921090450.807575-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemk200008.china.huawei.com (7.202.194.74) Content-Type: text/plain; charset="utf-8" On 32-bit x86 systems with HIGHMEM, kmap_local_page() only maps a single 4KB page. However, the elfcorehdr segment can span several pages (up to hundreds of kilobytes). The original code blindly copies 'elfsz' bytes at once via memcpy_flushcache(), overwriting adjacent fixmap entries or critical virtual addresses. Fix this by copying the new elfcorehdr page by page. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: "H. Peter Anvin" Cc: "Mike Rapoport (Microsoft)" Cc: Vishal Verma Cc: Baoquan He Cc: Chao Gao Cc: Sean Christopherson Cc: Eric DeVolder Cc: Hari Bathini Cc: Andrew Morton Cc: Sourabh Jain Cc: stable@vger.kernel.org Fixes: ea53ad9cf73b ("x86/crash: add x86 crash hotplug support") Link: https://sashiko.dev/#/patchset/20260907125404.922123-1-ruanjinjie%40h= uawei.com Signed-off-by: Jinjie Ruan --- arch/x86/kernel/crash.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c index e681ec9cf1dc..3c9f4fbbe7ff 100644 --- a/arch/x86/kernel/crash.c +++ b/arch/x86/kernel/crash.c @@ -447,9 +447,10 @@ unsigned int arch_crash_get_elfcorehdr_size(void) */ void arch_crash_handle_hotplug_event(struct kimage *image, void *arg) { - void *elfbuf =3D NULL, *old_elfcorehdr; unsigned long mem, memsz; unsigned long elfsz =3D 0; + void *elfbuf =3D NULL; + unsigned long done; =20 /* * As crash_prepare_elf64_headers() has already described all @@ -484,21 +485,20 @@ void arch_crash_handle_hotplug_event(struct kimage *i= mage, void *arg) =20 /* * Copy new elfcorehdr over the old elfcorehdr at destination. - */ - old_elfcorehdr =3D kmap_local_page(pfn_to_page(mem >> PAGE_SHIFT)); - if (!old_elfcorehdr) { - pr_err("mapping elfcorehdr segment failed\n"); - goto out; - } - - /* - * Temporarily invalidate the crash image while the - * elfcorehdr is updated. + * The segment is physically contiguous but can span several pages. + * On 32-bit Highmem architectures, kmap_local_page() maps only a + * single page at a time, so copy page by page. */ xchg(&kexec_crash_image, NULL); - memcpy_flushcache(old_elfcorehdr, elfbuf, elfsz); + for (done =3D 0; done < elfsz; ) { + size_t chunk =3D min_t(size_t, PAGE_SIZE, elfsz - done); + void *dst =3D kmap_local_page(pfn_to_page((mem + done) >> PAGE_SHIFT)); + + memcpy_flushcache(dst, elfbuf + done, chunk); + kunmap_local(dst); + done +=3D chunk; + } xchg(&kexec_crash_image, image); - kunmap_local(old_elfcorehdr); pr_debug("updated elfcorehdr\n"); =20 out: --=20 2.34.1 From nobody Thu Sep 24 20:03:35 2026 Received: from canpmsgout10.his.huawei.com (canpmsgout10.his.huawei.com [113.46.200.225]) (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 897D046AA66 for ; Mon, 21 Sep 2026 09:04:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.225 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981467; cv=none; b=UDE+ab66NUlPcK5tE2gqQCbwyzEz5PFtnTWPY3TSMJ7dvDGikHzZeaHhZO3BSI+4+DhsTBpdwBDJjX1S0l5mz/R/ivt509OYmuCf3yBQNL3nMEWucGFwEfJ3lHkMP96BjpXgpYHRMMR0i2L4PcKVKWxzZz9KdKndfl3ui0qTLdA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981467; c=relaxed/simple; bh=2KdupsWceweyWYND6ijvaYhreMt2HBNEZIG8MHJnBs8=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=IxHnGDR8SWAyQ5jFY86X7hZwYxBeAl0weZKVXyd6CKkbTs3qa+N8Rk29M7U1fisIZFnUfbyofg9hKlCYUvLq1Jell1+TxV/kfwxDtUrcDwjO+4ysAi7Q0UwsBTkocVQOoefPk9ka0Zk/ATZuR+S2asjnVR57c+feovDRyw15oqc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=QDOtzo0Y; arc=none smtp.client-ip=113.46.200.225 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="QDOtzo0Y" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=+SZRrezQ0aGrf6aoi2mjbpyD9DzDa0MzzJwmMo2zVh0=; b=QDOtzo0YbEPraF8hBNN1eIHHylUMG/0f8u5ka7yGUNTwM1OnOYxP9zWXeAlrcrPh3LHLBghb2 nIQRJeX/fS4RhMOLtRND7crtI/jS6NinldAxrfL97sRs7OyUEmKcrvK/a+f42xeMlDcgBE0logz Y70h41sj0wu9iQS94ph0bQ8= Received: from mail.maildlp.com (unknown [172.19.163.127]) by canpmsgout10.his.huawei.com (SkyGuard) with ESMTPS id 4hpH7Y2wKfz1K9XH; Mon, 21 Sep 2026 16:53:13 +0800 (CST) Received: from kwepemk200008.china.huawei.com (unknown [7.202.194.74]) by mail.maildlp.com (Postfix) with ESMTPS id 50C9D402AB; Mon, 21 Sep 2026 17:04:15 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemk200008.china.huawei.com (7.202.194.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 21 Sep 2026 17:04:13 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v6 10/14] crash: Extract crash_get_memory_ranges() helper Date: Mon, 21 Sep 2026 17:04:46 +0800 Message-ID: <20260921090450.807575-11-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260921090450.807575-1-ruanjinjie@huawei.com> References: <20260921090450.807575-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemk200008.china.huawei.com (7.202.194.74) Content-Type: text/plain; charset="utf-8" Factor out the crash memory range collection logic from crash_prepare_headers() into a separate function. This allows the memory hotplug path to obtain and modify the range list (e.g. remove offlined memory) before generating the elfcorehdr. Cc: Andrew Morton Cc: Baoquan He Cc: Mike Rapoport Cc: Pasha Tatashin Cc: Pratyush Yadav Cc: Dave Young Signed-off-by: Jinjie Ruan --- include/linux/crash_core.h | 1 + kernel/crash_core.c | 22 +++++++++++++++++++--- 2 files changed, 20 insertions(+), 3 deletions(-) diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h index bc087124cd78..b1c816e98143 100644 --- a/include/linux/crash_core.h +++ b/include/linux/crash_core.h @@ -62,6 +62,7 @@ extern int crash_prepare_elf64_headers(struct crash_mem *= mem, int need_kernel_ma extern int crash_prepare_headers(int need_kernel_map, void **addr, unsigned long *sz, unsigned long *nr_mem_ranges); extern int crash_exclude_core_ranges(struct crash_mem **cmem); +int crash_get_memory_ranges(struct crash_mem **mem_ranges); =20 struct kimage; struct kexec_segment; diff --git a/kernel/crash_core.c b/kernel/crash_core.c index 2b36aa9fade0..406b68d2adfd 100644 --- a/kernel/crash_core.c +++ b/kernel/crash_core.c @@ -317,8 +317,7 @@ int crash_exclude_core_ranges(struct crash_mem **cmem) return 0; } =20 -int crash_prepare_headers(int need_kernel_map, void **addr, unsigned long = *sz, - unsigned long *nr_mem_ranges) +int crash_get_memory_ranges(struct crash_mem **mem_ranges) { unsigned int max_nr_ranges; struct crash_mem *cmem; @@ -344,13 +343,30 @@ int crash_prepare_headers(int need_kernel_map, void *= *addr, unsigned long *sz, if (ret) goto out; =20 + *mem_ranges =3D cmem; + return 0; + +out: + kvfree(cmem); + return ret; +} + +int crash_prepare_headers(int need_kernel_map, void **addr, unsigned long = *sz, + unsigned long *nr_mem_ranges) +{ + struct crash_mem *cmem =3D NULL; + int ret; + + ret =3D crash_get_memory_ranges(&cmem); + if (ret) + return ret; + /* Return the computed number of memory ranges, for hotplug usage */ if (nr_mem_ranges) *nr_mem_ranges =3D cmem->nr_ranges; =20 ret =3D crash_prepare_elf64_headers(cmem, need_kernel_map, addr, sz); =20 -out: kvfree(cmem); return ret; } --=20 2.34.1 From nobody Thu Sep 24 20:03:35 2026 Received: from canpmsgout10.his.huawei.com (canpmsgout10.his.huawei.com [113.46.200.225]) (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 896C146AA65 for ; Mon, 21 Sep 2026 09:04:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.225 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981468; cv=none; b=UsFQHOAFXARpW+yE5ihhaLOrAZC6V+/kHjCwmS1/9k0KNXIook+mqGJH98KzmdtlHKM4KCSg8PEGW0hGl/cs7uGVAexA5W59r++cYxmP/R3d/pNbgSqzxwgK+xb5LQsLzIpv5g5fdgTl5W9xyIivTKMgk9E8EEmlx1m0/wkxx34= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981468; c=relaxed/simple; bh=bSE83igYe1W35rdRuNP69UJytL/ftjAhu118zl3lzcA=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=AcnMwkaVA+c4ACZEu6OlVYWPD/xePpdkFUP5XgEZD1cZszn/xne8drKpIZdQDeYHidervcf/aYMBhAaIPkXOE2P0DVuDMSheLsb2uictoke2zLzeDShapgwk3O7C20nf1hrSNEyUPNuS5oFEf4VM3n9fYm9NEyKzjyYHlnGpjFk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=Xk3K1Lag; arc=none smtp.client-ip=113.46.200.225 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="Xk3K1Lag" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=oJTPjIaIqy30CyW5gdpqj1ltYgKaERSOMcSOuwRttqY=; b=Xk3K1Lag16/7PUJwSJwRKAWcXn51YKwa9K4bTVig/jzNn34hk7LewtIKmtx+01VSKzFVqRzzQ wGiFlBwGpaMhKzr9S/eyYz1vcdeUtXIbZr9e9FiAHiBznYDu4EF1evoWFkMInlmtdm/yuNtiMKX /P1HTZPUO81RTQgB5/AToOM= Received: from mail.maildlp.com (unknown [172.19.163.15]) by canpmsgout10.his.huawei.com (SkyGuard) with ESMTPS id 4hpH7b1rDqz1K9D2; Mon, 21 Sep 2026 16:53:15 +0800 (CST) Received: from kwepemk200008.china.huawei.com (unknown [7.202.194.74]) by mail.maildlp.com (Postfix) with ESMTPS id 2860E40586; Mon, 21 Sep 2026 17:04:17 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemk200008.china.huawei.com (7.202.194.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 21 Sep 2026 17:04:15 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v6 11/14] crash: Factor out crash_find_elfcorehdr() helper Date: Mon, 21 Sep 2026 17:04:47 +0800 Message-ID: <20260921090450.807575-12-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260921090450.807575-1-ruanjinjie@huawei.com> References: <20260921090450.807575-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemk200008.china.huawei.com (7.202.194.74) Content-Type: text/plain; charset="utf-8" The elfcorehdr segment is located by scanning the segments for the ELF magic. Factor that scan out into a new helper function, crash_find_elfcorehdr(), to clean up crash_handle_hotplug_event() and prepare for its reuse in crash hotplug code. Cc: Andrew Morton Cc: Baoquan He Cc: Mike Rapoport Cc: Pasha Tatashin Cc: Pratyush Yadav Cc: Dave Young Cc: Breno Leitao Signed-off-by: Jinjie Ruan --- kernel/crash_core.c | 39 +++++++++++++++++++++++---------------- 1 file changed, 23 insertions(+), 16 deletions(-) diff --git a/kernel/crash_core.c b/kernel/crash_core.c index 406b68d2adfd..4a990b17b66c 100644 --- a/kernel/crash_core.c +++ b/kernel/crash_core.c @@ -647,6 +647,28 @@ int crash_check_hotplug_support(void) return rc; } =20 +static void crash_find_elfcorehdr(struct kimage *image) +{ + unsigned char *ptr; + unsigned long mem; + unsigned int n; + + if (image->elfcorehdr_index >=3D 0) + return; + + for (n =3D 0; n < image->nr_segments; n++) { + mem =3D image->segment[n].mem; + ptr =3D kmap_local_page(pfn_to_page(mem >> PAGE_SHIFT)); + if (!ptr) + continue; + + /* The segment containing elfcorehdr */ + if (memcmp(ptr, ELFMAG, SELFMAG) =3D=3D 0) + image->elfcorehdr_index =3D (int)n; + kunmap_local(ptr); + } +} + /* * To accurately reflect hot un/plug changes of CPU and Memory resources * (including onling and offlining of those resources), the relevant @@ -702,22 +724,7 @@ static void crash_handle_hotplug_event(unsigned int hp= _action, unsigned int cpu, * is allocated. Find the segment containing the elfcorehdr, * if not already found. */ - if (image->elfcorehdr_index < 0) { - unsigned long mem; - unsigned char *ptr; - unsigned int n; - - for (n =3D 0; n < image->nr_segments; n++) { - mem =3D image->segment[n].mem; - ptr =3D kmap_local_page(pfn_to_page(mem >> PAGE_SHIFT)); - if (ptr) { - /* The segment containing elfcorehdr */ - if (memcmp(ptr, ELFMAG, SELFMAG) =3D=3D 0) - image->elfcorehdr_index =3D (int)n; - kunmap_local(ptr); - } - } - } + crash_find_elfcorehdr(image); =20 if (image->elfcorehdr_index < 0) { pr_err("unable to locate elfcorehdr segment"); --=20 2.34.1 From nobody Thu Sep 24 20:03:35 2026 Received: from canpmsgout01.his.huawei.com (canpmsgout01.his.huawei.com [113.46.200.216]) (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 6C78346A618 for ; Mon, 21 Sep 2026 09:04:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.216 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981467; cv=none; b=j19CZGb4xtw5VgOpIWOXw33KqkJRasTMffCM+4ysxEyc4HdBkKx9ot9eIx7VZOkzmq4yEzXHFfLzz2ZmMH8TBcxAgK//UJAZLLGXB7F2xCDgRTgsXquVLuzFHArX///VC9ugspz426PXsVlbS22yRDsPbQQLYGCE4cnmkOgGqRc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981467; c=relaxed/simple; bh=v1PIGl5kIDm5VJPlCpcSMBeCAhXfmoqojAnqlImGKnM=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=oRHEvDZo9q4NsxgUEURJv7/SIPRIR7rEWIqEJr00D52sYzCCZgolKxZLw0CJQX8+z1zsS2hwBQh1E9DBW0T4Ce8RHLg99qSUqlq80r/WPP9Non7GBh0aGj3SJ3irP9XAMOMZb1Q2cpxi8Hn8y1wiSslIcrNEPI5mmMW2HP3yKMw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=swlmKcZ4; arc=none smtp.client-ip=113.46.200.216 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="swlmKcZ4" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=VZIZGRolM7FCO6UO6yMcsvIDaO/72RZY1KyJwAZOdU4=; b=swlmKcZ4cG/2bdOnxIUkMBXNXy3omsNeGbQIDwff1HvWDlARUorsoyxZCAK//EdS2+2G4ESec o0BFV3Vl7vbxgN30Qu1KxnXYPqLm8BCX7wVMkN2NC9zvSlN60p1gEudxr6CEvj9g4E93n8mgBzo O82+QYGukKF8XoClAUarmy4= Received: from mail.maildlp.com (unknown [172.19.162.197]) by canpmsgout01.his.huawei.com (SkyGuard) with ESMTPS id 4hpH6k2j01z1T4Fq; Mon, 21 Sep 2026 16:52:30 +0800 (CST) Received: from kwepemk200008.china.huawei.com (unknown [7.202.194.74]) by mail.maildlp.com (Postfix) with ESMTPS id E2B154057D; Mon, 21 Sep 2026 17:04:18 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemk200008.china.huawei.com (7.202.194.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 21 Sep 2026 17:04:16 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v6 12/14] crash: Normalize the kexec_load elfcorehdr at load time Date: Mon, 21 Sep 2026 17:04:48 +0800 Message-ID: <20260921090450.807575-13-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260921090450.807575-1-ruanjinjie@huawei.com> References: <20260921090450.807575-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemk200008.china.huawei.com (7.202.194.74) Content-Type: text/plain; charset="utf-8" For kexec_load() the kernel does not build the elfcorehdr, so it is only rewritten by the first crash hotplug event. CPU hotplug events do not change the elfcorehdr, but they may run without device_hotplug_lock (e.g. CPU offlining during suspend), so they cannot perform that rewrite without racing with memory hotplug. Normalize the elfcorehdr once when the crash image is installed via crash_hotplug_prepare_elfcorehdr(), while device_hotplug_lock can still be taken safely, and let the hotplug paths skip CPU events entirely. Architectures that do not need the rewrite (e.g. powerpc) treat KEXEC_CRASH_HP_NONE as a no-op. The x86 crash hotplug handler now skips CPU hotplug events unconditionally, so nothing reads image->elfcorehdr_updated anymore. Drop the field and the code that maintains it. Slightly tested on x86_64 with kexec_load (--kexec-syscall --hotplug), it boots successfully into the second kernel. Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Nicholas Piggin Cc: "Christophe Leroy (CS GROUP)" Cc: "Ritesh Harjani (IBM)" Cc: Shrikanth Hegde Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: "H. Peter Anvin" Cc: Andrew Morton Cc: Baoquan He Cc: Mike Rapoport Cc: Pasha Tatashin Cc: Pratyush Yadav Cc: Dave Young Cc: Sourabh Jain Signed-off-by: Jinjie Ruan --- arch/powerpc/kexec/crash.c | 1 + arch/x86/kernel/crash.c | 5 ++--- include/linux/crash_core.h | 1 + include/linux/kexec.h | 1 - kernel/crash_core.c | 20 +++++++++++++++++++- kernel/kexec.c | 4 ++++ kernel/kexec_core.c | 1 - 7 files changed, 27 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c index 775895f31037..8ede33740fc0 100644 --- a/arch/powerpc/kexec/crash.c +++ b/arch/powerpc/kexec/crash.c @@ -638,6 +638,7 @@ void arch_crash_handle_hotplug_event(struct kimage *ima= ge, void *arg) struct memory_notify *mn; =20 switch (image->hp_action) { + case KEXEC_CRASH_HP_NONE: case KEXEC_CRASH_HP_REMOVE_CPU: return; =20 diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c index 3c9f4fbbe7ff..f34fa8dba028 100644 --- a/arch/x86/kernel/crash.c +++ b/arch/x86/kernel/crash.c @@ -457,9 +457,8 @@ void arch_crash_handle_hotplug_event(struct kimage *ima= ge, void *arg) * possible CPUs, there is no need to update the elfcorehdr * for additional CPU changes. */ - if ((image->file_mode || image->elfcorehdr_updated) && - ((image->hp_action =3D=3D KEXEC_CRASH_HP_ADD_CPU) || - (image->hp_action =3D=3D KEXEC_CRASH_HP_REMOVE_CPU))) + if (image->hp_action =3D=3D KEXEC_CRASH_HP_ADD_CPU || + image->hp_action =3D=3D KEXEC_CRASH_HP_REMOVE_CPU) return; =20 /* diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h index b1c816e98143..a740757dff35 100644 --- a/include/linux/crash_core.h +++ b/include/linux/crash_core.h @@ -39,6 +39,7 @@ static inline void arch_crash_handle_hotplug_event(struct= kimage *image, void *a #endif =20 int crash_check_hotplug_support(void); +void crash_hotplug_prepare_elfcorehdr(struct kimage *image); =20 #ifndef arch_crash_hotplug_support static inline int arch_crash_hotplug_support(struct kimage *image, unsigne= d long kexec_flags) diff --git a/include/linux/kexec.h b/include/linux/kexec.h index 72258d813301..f1f218e46db0 100644 --- a/include/linux/kexec.h +++ b/include/linux/kexec.h @@ -404,7 +404,6 @@ struct kimage { #ifdef CONFIG_CRASH_HOTPLUG int hp_action; int elfcorehdr_index; - bool elfcorehdr_updated; #endif =20 #ifdef CONFIG_IMA_KEXEC diff --git a/kernel/crash_core.c b/kernel/crash_core.c index 4a990b17b66c..b638ad0e5ba2 100644 --- a/kernel/crash_core.c +++ b/kernel/crash_core.c @@ -742,7 +742,6 @@ static void crash_handle_hotplug_event(unsigned int hp_= action, unsigned int cpu, =20 /* No longer handling a hotplug event */ image->hp_action =3D KEXEC_CRASH_HP_NONE; - image->elfcorehdr_updated =3D true; =20 /* Change back to read-only */ arch_kexec_protect_crashkres(); @@ -754,6 +753,25 @@ static void crash_handle_hotplug_event(unsigned int hp= _action, unsigned int cpu, crash_hotplug_unlock(); } =20 +void crash_hotplug_prepare_elfcorehdr(struct kimage *image) +{ + if (!image || !image->hotplug_support || image->file_mode) + return; + + crash_find_elfcorehdr(image); + if (image->elfcorehdr_index < 0) + return; + + /* + * kexec_load() images are not normalized at load, so do it here while + * the lock is still free to take. hp_action is KEXEC_CRASH_HP_NONE, + * which the arch handler treats as "just rebuild the elfcorehdr". + */ + lock_device_hotplug(); + arch_crash_handle_hotplug_event(image, NULL); + unlock_device_hotplug(); +} + static int crash_memhp_notifier(struct notifier_block *nb, unsigned long v= al, void *arg) { switch (val) { diff --git a/kernel/kexec.c b/kernel/kexec.c index 90756dc6339b..ea9ba00bc786 100644 --- a/kernel/kexec.c +++ b/kernel/kexec.c @@ -166,6 +166,10 @@ static int do_kexec_load(unsigned long entry, unsigned= long nr_segments, /* Install the new kernel and uninstall the old */ image =3D xchg(dest_image, image); =20 +#ifdef CONFIG_CRASH_HOTPLUG + if ((flags & KEXEC_ON_CRASH) && kexec_crash_image) + crash_hotplug_prepare_elfcorehdr(kexec_crash_image); +#endif out: #ifdef CONFIG_CRASH_DUMP if ((flags & KEXEC_ON_CRASH) && kexec_crash_image) diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c index 31c8228318a7..c36a5e8b400e 100644 --- a/kernel/kexec_core.c +++ b/kernel/kexec_core.c @@ -251,7 +251,6 @@ struct kimage *do_kimage_alloc_init(void) #ifdef CONFIG_CRASH_HOTPLUG image->hp_action =3D KEXEC_CRASH_HP_NONE; image->elfcorehdr_index =3D -1; - image->elfcorehdr_updated =3D false; #endif =20 return image; --=20 2.34.1 From nobody Thu Sep 24 20:03:35 2026 Received: from canpmsgout07.his.huawei.com (canpmsgout07.his.huawei.com [113.46.200.222]) (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 AC97D45D921 for ; Mon, 21 Sep 2026 09:04:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.222 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981484; cv=none; b=Qan16o5T1VxKHsamg9ld8OoGEdqmQVGNTceqS4dB9YP98saRkwZSzAm8Qr78fpr1l39PxUi48t0YgKAk6fFAgVQpxe5NG6S+BNdLcHimEY57KzRaboWkdmP+P5L4O874sVemWJwhZNP4C7pgKF+x24qRbhOPZ5/LVeLwQs7a7a4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981484; c=relaxed/simple; bh=KhKa8DVQaDkX5yqLgcINt9w9yBbAaKqcrPXHUwXdLVs=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=LafTexldHhSV+3HBauIQTH0gRXwhmRE8Nx/3P7u9zs1ixn/7yiEzKooAU2dAoUJWVqvKVmo/mjcS1TyAODpyLEPDpvQvq5PQm40/smzyAjxYW4zjsdjTLc4MyqBIO0P8NPG9V0QifF/6Q4psVutZbAZNuwyZBGCcV9Tyh9C+0v4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=NLfB55gt; arc=none smtp.client-ip=113.46.200.222 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="NLfB55gt" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=7Gly1btZ/qtetqt6PZXoWzbx2dJha17PF7md6d6YHEg=; b=NLfB55gt4vcsyPjJv21R+FR/t3i0Zfpu9+ajOViW02naV5Sz3HgaYwJgkq03z4u4M068FVcuf v6HCRypcJ9fT+TroC7eKOYwp9DB7wJNdWeXuUop0ibOhPKdLIrdyTrXZnTAIan70wbc0IB+MKEM pjgvJWFJlJ9pg7owuY6S8R8= Received: from mail.maildlp.com (unknown [172.19.163.15]) by canpmsgout07.his.huawei.com (SkyGuard) with ESMTPS id 4hpH7w69Z7zLlTm; Mon, 21 Sep 2026 16:53:32 +0800 (CST) Received: from kwepemk200008.china.huawei.com (unknown [7.202.194.74]) by mail.maildlp.com (Postfix) with ESMTPS id 91E6B4058E; Mon, 21 Sep 2026 17:04:34 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemk200008.china.huawei.com (7.202.194.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 21 Sep 2026 17:04:18 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v6 13/14] driver core: Add device_hotplug_lock_assert_held() helper Date: Mon, 21 Sep 2026 17:04:49 +0800 Message-ID: <20260921090450.807575-14-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260921090450.807575-1-ruanjinjie@huawei.com> References: <20260921090450.807575-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemk200008.china.huawei.com (7.202.194.74) Content-Type: text/plain; charset="utf-8" crash_get_memory_ranges() walks memblock, which memory hotplug modifies under device_hotplug_lock. A caller that does not hold the lock can race with memblock_double_array() and iterate a freed regions array. Add device_hotplug_lock_assert_held() so that crash code can use it to catch such unsafe callers via lockdep. Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: Danilo Krummrich Signed-off-by: Jinjie Ruan --- drivers/base/core.c | 5 +++++ include/linux/device.h | 1 + 2 files changed, 6 insertions(+) diff --git a/drivers/base/core.c b/drivers/base/core.c index 4c0c373998a1..c04adc457a96 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -2420,6 +2420,11 @@ void unlock_device_hotplug(void) mutex_unlock(&device_hotplug_lock); } =20 +void device_hotplug_lock_assert_held(void) +{ + lockdep_assert_held(&device_hotplug_lock); +} + int lock_device_hotplug_sysfs(void) { if (mutex_trylock(&device_hotplug_lock)) diff --git a/include/linux/device.h b/include/linux/device.h index aee79fd6b32b..9cca8c8bd372 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -1261,6 +1261,7 @@ do { \ void lock_device_hotplug(void); void unlock_device_hotplug(void); int lock_device_hotplug_sysfs(void); +void device_hotplug_lock_assert_held(void); int device_offline(struct device *dev); int device_online(struct device *dev); =20 --=20 2.34.1 From nobody Thu Sep 24 20:03:35 2026 Received: from canpmsgout10.his.huawei.com (canpmsgout10.his.huawei.com [113.46.200.225]) (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 7FDEE463B9A for ; Mon, 21 Sep 2026 09:04:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.225 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981486; cv=none; b=hG+pHEeYpXN+thVozew3HuizHXN/58Kz5K76/WF94ZUI2y3zahZopNeh9PABtU4WMN1+uUl5zg3AYMDwhqUV3wrteTQmNufPs7qAJwgdQXYkTCz9gVJ5QnB8PP5f468kcgovolidCSNLcHZiRbD6PuBL3tdTukUE9ixFnUaDYno= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789981486; c=relaxed/simple; bh=/nVm6xRwzy2pvX3Na86ULlC7BaHWJKYqo5LtpJ2aCL4=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=QX5JUC9oJedJn8jX1cHH8sAex2d4qNBeVnj5F0ti7HkifaNLa9XrfptiVIVjECY+C7bg2VdKLx7QySzzYevVi5GNiiwqnR19pLjCWBhss3SuCwkta3pQdr4bitDvIyMXiIoPhIX4ARHDoMkW8+J+heCPHiI80g2pRkRlN4YXJ+U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=FSQCRI07; arc=none smtp.client-ip=113.46.200.225 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="FSQCRI07" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=tZDkeXV6a369nstMRHLxqf/4pglLnuU252K/oM3e//U=; b=FSQCRI07g5QzFIcDMwCwg/ym4bv+MAK0v8zfemlvrSwKiabVebvUXPWom1TVv4gzGf8buXlLy RMYyu38fBRkQyRbfO+5BpR3c6LEShSJE+2OjrybC1bDiGSgDcbIKCxFkfXpl37nLLre31VHPXRY sgFKRo0j3+ZlmM8+lt2rpds= Received: from mail.maildlp.com (unknown [172.19.163.15]) by canpmsgout10.his.huawei.com (SkyGuard) with ESMTPS id 4hpH7w5X96z1K9Ck; Mon, 21 Sep 2026 16:53:32 +0800 (CST) Received: from kwepemk200008.china.huawei.com (unknown [7.202.194.74]) by mail.maildlp.com (Postfix) with ESMTPS id A928D40592; Mon, 21 Sep 2026 17:04:34 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemk200008.china.huawei.com (7.202.194.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 21 Sep 2026 17:04:20 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v6 14/14] crash: Fix TOCTOU race in crash memory range collection Date: Mon, 21 Sep 2026 17:04:50 +0800 Message-ID: <20260921090450.807575-15-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260921090450.807575-1-ruanjinjie@huawei.com> References: <20260921090450.807575-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemk200008.china.huawei.com (7.202.194.74) Content-Type: text/plain; charset="utf-8" The crash kernel ELF core header construction counts system memory ranges via `arch_get_system_nr_ranges()`, allocates the crash_mem buffer, and then populates it via `arch_crash_populate_cmem()`. This sequence has a time-of-check-to-time-of-use (TOCTOU) race with memory hotplug: a concurrent hotplug event between the count and populate steps can increase the number of ranges beyond the allocated capacity, causing an out-of-bounds write. If the event triggers memblock_double_array(), the memblock array can be freed and reallocated during iteration, leading to a use-after-free. Protect the entire range collection with device_hotplug_lock. Since the hotplug notification path already holds that lock, add a lockless helper, crash_get_memory_ranges_nolock(), for use there. The regular crash_get_memory_ranges() acquires the lock and calls the helper. Cc: stable@vger.kernel.org Cc: Andrew Morton Cc: Baoquan He Cc: Mike Rapoport Cc: Pasha Tatashin Cc: Pratyush Yadav Cc: Dave Young Cc: AKASHI Takahiro Cc: Will Deacon Cc: James Morse Cc: Palmer Dabbelt Cc: Youling Tang Cc: Huacai Chen Cc: Breno Leitao Fixes: 8d5f894a3108 ("x86: kexec_file: lift CRASH_MAX_RANGES limit on crash= _mem buffer") Fixes: 3751e728cef2 ("arm64: kexec_file: add crash dump support") Fixes: 8acea455fafa ("RISC-V: Support for kexec_file on panic") Fixes: 1bcca8620a91 ("LoongArch: Add crash dump support for kexec_file") Link: https://sashiko.dev/#/patchset/20260729031235.2840255-1-ruanjinjie%40= huawei.com Signed-off-by: Jinjie Ruan --- arch/x86/kernel/crash.c | 9 ++++++++- include/linux/crash_core.h | 2 +- kernel/crash_core.c | 35 ++++++++++++++++++++++++++++++++++- 3 files changed, 43 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c index f34fa8dba028..7fa139725514 100644 --- a/arch/x86/kernel/crash.c +++ b/arch/x86/kernel/crash.c @@ -447,6 +447,7 @@ unsigned int arch_crash_get_elfcorehdr_size(void) */ void arch_crash_handle_hotplug_event(struct kimage *image, void *arg) { + struct crash_mem *cmem =3D NULL; unsigned long mem, memsz; unsigned long elfsz =3D 0; void *elfbuf =3D NULL; @@ -461,11 +462,16 @@ void arch_crash_handle_hotplug_event(struct kimage *i= mage, void *arg) image->hp_action =3D=3D KEXEC_CRASH_HP_REMOVE_CPU) return; =20 + if (crash_get_memory_ranges_nolock(&cmem)) { + pr_err("Failed to get crash mem range\n"); + goto out; + } + /* * Create the new elfcorehdr reflecting the changes to CPU and/or * memory resources. */ - if (crash_prepare_headers(IS_ENABLED(CONFIG_X86_64), &elfbuf, &elfsz, NUL= L)) { + if (crash_prepare_elf64_headers(cmem, IS_ENABLED(CONFIG_X86_64), &elfbuf,= &elfsz)) { pr_err("unable to create new elfcorehdr"); goto out; } @@ -501,6 +507,7 @@ void arch_crash_handle_hotplug_event(struct kimage *ima= ge, void *arg) pr_debug("updated elfcorehdr\n"); =20 out: + kvfree(cmem); vfree(elfbuf); } #endif diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h index a740757dff35..1296a9b29974 100644 --- a/include/linux/crash_core.h +++ b/include/linux/crash_core.h @@ -63,7 +63,7 @@ extern int crash_prepare_elf64_headers(struct crash_mem *= mem, int need_kernel_ma extern int crash_prepare_headers(int need_kernel_map, void **addr, unsigned long *sz, unsigned long *nr_mem_ranges); extern int crash_exclude_core_ranges(struct crash_mem **cmem); -int crash_get_memory_ranges(struct crash_mem **mem_ranges); +int crash_get_memory_ranges_nolock(struct crash_mem **mem_ranges); =20 struct kimage; struct kexec_segment; diff --git a/kernel/crash_core.c b/kernel/crash_core.c index b638ad0e5ba2..43b21de1d64a 100644 --- a/kernel/crash_core.c +++ b/kernel/crash_core.c @@ -7,6 +7,7 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt =20 #include +#include #include #include #include @@ -317,12 +318,33 @@ int crash_exclude_core_ranges(struct crash_mem **cmem) return 0; } =20 -int crash_get_memory_ranges(struct crash_mem **mem_ranges) +/** + * crash_get_memory_ranges_nolock - Collect crash kernel memory ranges + * @mem_ranges: Output parameter for the allocated crash_mem structure + * + * Gathers the system memory ranges to be included in the crash kernel's + * ELF core header, excluding the crashkernel reserved region and other + * architecture-specific areas. + * + * Context: Caller must hold device_hotplug_lock. + * + * Return: 0 on success, in which case *@mem_ranges points to a newly + * allocated struct crash_mem that the caller must free with kvfree(). + * Returns a negative error code on failure. + */ +int crash_get_memory_ranges_nolock(struct crash_mem **mem_ranges) { unsigned int max_nr_ranges; struct crash_mem *cmem; int ret; =20 + /* + * Callers must serialize against memory hotplug by holding + * device_hotplug_lock, otherwise the memblock iteration below can + * race with memblock_double_array() and read freed memory. + */ + device_hotplug_lock_assert_held(); + max_nr_ranges =3D arch_get_system_nr_ranges(); if (!max_nr_ranges) return -ENOMEM; @@ -351,6 +373,17 @@ int crash_get_memory_ranges(struct crash_mem **mem_ran= ges) return ret; } =20 +static int crash_get_memory_ranges(struct crash_mem **mem_ranges) +{ + int ret; + + lock_device_hotplug(); + ret =3D crash_get_memory_ranges_nolock(mem_ranges); + unlock_device_hotplug(); + + return ret; +} + int crash_prepare_headers(int need_kernel_map, void **addr, unsigned long = *sz, unsigned long *nr_mem_ranges) { --=20 2.34.1