From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 624C539478D; Sat, 30 May 2026 18:36:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780166198; cv=none; b=tjerPvCF8OnvjJcOCzUm8ZPPyXxRZXBYzl6ZBPYuBOVAuOHKcHJcRImUz91PSP1OUlnjwlB4lvAjlEb4e14NlbF/krCpUUXNRB8Jo9cC9tt9v03AvO/tKb4cu4qgZ3VZxqagRjXccdga0gtNI6n7gdrjLH2ti5rEVq2GAr4qRl4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780166198; c=relaxed/simple; bh=NiLWoK/paNlpaxqAA5Ff7/id3zG9PNjHB3IIUM0+Tb8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=tQiaGSLy6unn3kwmrggz9pPW7tkiwXpV4kWLqKr1vVEZU7pMgVmUKxZU83Ph5tzJVCbxpyKcXpe9Qxd6NxMC3CFZ8DOlSMay3RKB0jkU6HElRusq+vbqA+7R3c7mjh8aqqK+aasJ7cJ0xOK+HGpV7LMfe1krUN7ugcWEYyyrwOw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=uVt2KCRw; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="uVt2KCRw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6FBD1F00893; Sat, 30 May 2026 18:36:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1780166197; bh=me7mO47Hq7Y3Ox4KLZvEK08m4bN4+gU1LYHMYujVAdk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=uVt2KCRwvpcARfhYM6sZT2migwSN9RWqQXMYh5GYHdkmDTwXfGQAp6LKSQznHkDGs rhyinjsV5S/bKMghYGuyidT4O/DY2VJV/8O393D20XtHKEvZEI8KcslEGLi4Z7/dZn wLHFM3w51cYdB7pE1cvCPY9h87K1Iyq0xRxSGslo= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Aditya Gupta , Sourabh Jain , Hari Bathini , Madhavan Srinivasan , Sasha Levin Subject: [PATCH 5.10 302/589] powerpc/crash: fix backup region offset update to elfcorehdr Date: Sat, 30 May 2026 18:03:03 +0200 Message-ID: <20260530160232.898204808@linuxfoundation.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260530160224.570625122@linuxfoundation.org> References: <20260530160224.570625122@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sourabh Jain [ Upstream commit 789335cacdf37da93bb7c70322dff8c7e82881df ] update_backup_region_phdr() in file_load_64.c iterates over all the program headers in the kdump kernel’s elfcorehdr and updates the p_offset of the program header whose physical address starts at 0. However, the loop logic is incorrect because the program header pointer is not updated during iteration. Since elfcorehdr typically contains PT_NOTE entries first, the PT_LOAD program header with physical address 0 is never reached. As a result, its p_offset is not updated to point to the backup region. Because of this behavior, the capture kernel exports the first 64 KB of the crashed kernel’s memory at offset 0, even though that memory actually lives in the backup region. When a crash happens, purgatory copies the first 64 KB of the crashed kernel’s memory into the backup region so the capture kernel can safely use it. This has not caused problems so far because the first 64 KB is usually identical in both the crashed and capture kernels. However, this is just an assumption and is not guaranteed to always hold true. Fix update_backup_region_phdr() to correctly update the p_offset of the program header with a starting physical address of 0 by correcting the logic used to iterate over the program headers. Fixes: cb350c1f1f86 ("powerpc/kexec_file: Prepare elfcore header for crashing kernel") Reviewed-by: Aditya Gupta Signed-off-by: Sourabh Jain Reviewed-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260312083051.1935737-2-sourabhjain@linux.ibm.com Signed-off-by: Sasha Levin --- arch/powerpc/kexec/file_load_64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kexec/file_load_64.c b/arch/powerpc/kexec/file_load_64.c index cb3fc0042cc25..9b4fdb47b9ba6 100644 --- a/arch/powerpc/kexec/file_load_64.c +++ b/arch/powerpc/kexec/file_load_64.c @@ -766,7 +766,7 @@ static void update_backup_region_phdr(struct kimage *image, Elf64_Ehdr *ehdr) unsigned int i; phdr = (Elf64_Phdr *)(ehdr + 1); - for (i = 0; i < ehdr->e_phnum; i++) { + for (i = 0; i < ehdr->e_phnum; i++, phdr++) { if (phdr->p_paddr == BACKUP_SRC_START) { phdr->p_offset = image->arch.backup_start; pr_debug("Backup region offset updated to 0x%lx\n", -- 2.53.0