From nobody Tue Sep 16 16:02:21 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C3837C3DA7A for ; Mon, 2 Jan 2023 10:39:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232322AbjABKjo (ORCPT ); Mon, 2 Jan 2023 05:39:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47422 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229707AbjABKjh (ORCPT ); Mon, 2 Jan 2023 05:39:37 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 038791D0; Mon, 2 Jan 2023 02:39:36 -0800 (PST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 6936B205F5; Mon, 2 Jan 2023 10:39:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1672655975; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=9xe2eMFnILH/jDMx9pAFzxHyWx3I3CkIiF3DU9xLhJ8=; b=0TVeymCcyKqOOeieQacnsxkc9lkFjJHsY0Bx+WH8TpER8kYx6pSvC3p95SUxNqBmRJXXZu oEDQh+trA1qBRrZPcdeQ/yBTOvyd1Jd8mP0/ivtD4rN64oLaPW6fL65YsdvIr0kAcV8ns5 Ax0WsI+B+EeBeOWoLo8F6TaJLo9nAus= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1672655975; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=9xe2eMFnILH/jDMx9pAFzxHyWx3I3CkIiF3DU9xLhJ8=; b=WsrHznqV/LCPAzulNABvB/gmrJzHu2rHQcOoBbLOw1q/9xrgv/YG3zOFUhtVwZhbL4Rh4E j0zynpfNBY+XZ6Bw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 3F2F013427; Mon, 2 Jan 2023 10:39:35 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id wIbCDme0smP3WgAAMHmgww (envelope-from ); Mon, 02 Jan 2023 10:39:35 +0000 From: Vlastimil Babka To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen Cc: x86@kernel.org, "H. Peter Anvin" , patches@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Vlastimil Babka , Baoquan He , Dave Young , stable@vger.kernel.org Subject: [PATCH] x86/kexec: fix double vfree of image->elf_headers Date: Mon, 2 Jan 2023 11:39:17 +0100 Message-Id: <20230102103917.20987-1-vbabka@suse.cz> X-Mailer: git-send-email 2.39.0 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" An investigation of a "Trying to vfree() nonexistent vm area" bug occurring in arch_kimage_file_post_load_cleanup() doing a vfree(image->elf_headers) in our 5.14-based kernel yielded the following double vfree() scenario, also present in mainline: SYSCALL_DEFINE5(kexec_file_load) kimage_file_alloc_init() kimage_file_prepare_segments() arch_kexec_kernel_image_probe() kexec_image_load_default() kexec_bzImage64_ops.load() bzImage64_load() crash_load_segments() prepare_elf_headers(image, &kbuf.buffer, &kbuf.bufsz); image->elf_headers =3D kbuf.buffer; ret =3D kexec_add_buffer(&kbuf); if (ret) vfree((void *)image->elf_headers); // first vfree() if (ret) kimage_file_post_load_cleanup() vfree(image->elf_headers); // second vfree= () AFAICS the scenario is possible since v5.19 commit b3e34a47f989 ("x86/kexec: fix memory leak of elf header buffer") that was marked for stable and also was backported to our kernel. Fix the problem by setting the pointer to NULL after the first vfree(). Also set elf_headers_sz to 0, as kimage_file_post_load_cleanup() does. Fixes: b3e34a47f989 ("x86/kexec: fix memory leak of elf header buffer") Signed-off-by: Vlastimil Babka Cc: Baoquan He Cc: Dave Young Cc: --- arch/x86/kernel/crash.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c index 9730c88530fc..0d651c05a49e 100644 --- a/arch/x86/kernel/crash.c +++ b/arch/x86/kernel/crash.c @@ -403,6 +403,8 @@ int crash_load_segments(struct kimage *image) ret =3D kexec_add_buffer(&kbuf); if (ret) { vfree((void *)image->elf_headers); + image->elf_headers =3D NULL; + image->elf_headers_sz =3D 0; return ret; } image->elf_load_addr =3D kbuf.mem; --=20 2.39.0