X-Received: by 2002:a05:6808:170b:b0:2ce:6a75:b87b with SMTP id bc11-20020a056808170b00b002ce6a75b87bmr330095oib.322.1645635980362; Wed, 23 Feb 2022 09:06:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645635980; cv=none; d=google.com; s=arc-20160816; b=Cazut9XGcH9VydKsKdeMtNupuCkm1IAXOZi5Azln3iSYKAZWAlp3GFva6KjQ7rGOOh n9BNLg+A8gaPaBtPhrSqN5nFrnaw1PKPvWc5ueTXdFpf0RVbqkzLu8xQgmGLD15zE5PP 3HSsIMrnDkFA3lnoAoyNI4GlKsu1B0NvoaWgmU1EnUNvbbZYbl3pBU4JD+PEmYfBkcHF x0GTGy6TIpww0qJatt63ZZgPxl9/+7ODc4LRkCcERvR7YnMyuKsUGJKiADe6YlMs0QO0 gKT1zaCA/D5LrY/twjJ112q70Ue/Es5nDBem08KEOY2QGeLM4ralAMsQeGmDoiu7mb3N atbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=8J0LUKv+K2TGv09wM1r8lu6xSXwGvPQQUKfT1lSG0mk=; b=sLbNI887uoZWjVLPL4ySewXr2NPFWjxSCRZsvD/1bZ+oXZFd6lyV+9vdGyrjeI4OUW ybw63xCBZxJjrz0ydPJ+u/n1dYgOFqgGaZm1yAN75rTYxOt1afgXAKkRiNxT201YQIqv loIENDxxspSt2cT5ZrG19aenREVeAiec7+Dujibzgwpr4TBF3TYedaFyaRoeEXKbumbq iZYT9XswsQ0MjA2HW5WQDFmEYGWGWzpzKQ4Up5lfQEc8EXIZmgB94e8DR+TT010KHi66 RZg5hkD2ZDfl0j/Hbad37V5OQv9qbB08TEb/vd3z1Fmt+D99u7GlWTrXQcO30I3L5rBR H6XA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="Cf5dGvM/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h6si53287oos.40.2022.02.23.09.06.01; Wed, 23 Feb 2022 09:06:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="Cf5dGvM/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239913AbiBWLd2 (ORCPT + 99 others); Wed, 23 Feb 2022 06:33:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49840 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239112AbiBWLdV (ORCPT ); Wed, 23 Feb 2022 06:33:21 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7D53D37BC2 for ; Wed, 23 Feb 2022 03:32:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1645615973; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8J0LUKv+K2TGv09wM1r8lu6xSXwGvPQQUKfT1lSG0mk=; b=Cf5dGvM/kKhEcE3SE0RyHMIVPgHx7viyBPTf2U+S+sd0QaiscHcVDmUaj6BYxLcYaCGcFs v9KlGfR3aIjv+OuJH9QT0hVOeD9X8h7//l94vMDAtBtlg+fBRslWCXCL6OkRgAT3cmEDQH 6qdaN+VkLuOzcQYzOA7ASAzQzQ63/1A= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-376-_MIicgExN0egWxn7o6VzRw-1; Wed, 23 Feb 2022 06:32:52 -0500 X-MC-Unique: _MIicgExN0egWxn7o6VzRw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3657A801AAD; Wed, 23 Feb 2022 11:32:51 +0000 (UTC) Received: from MiWiFi-R3L-srv.smartont.net (ovpn-13-167.pek2.redhat.com [10.72.13.167]) by smtp.corp.redhat.com (Postfix) with ESMTP id A34A0797C4; Wed, 23 Feb 2022 11:32:48 +0000 (UTC) From: Baoquan He To: linux-kernel@vger.kernel.org Cc: kexec@lists.infradead.org, dyoung@redhat.com, akpm@linux-foundation.org, bhe@redhat.com, x86@kernel.org, linux-mm@kvack.org Subject: [PATCH v2 1/2] x86/kexec: fix memory leak of elf header buffer Date: Wed, 23 Feb 2022 19:32:24 +0800 Message-Id: <20220223113225.63106-2-bhe@redhat.com> In-Reply-To: <20220223113225.63106-1-bhe@redhat.com> References: <20220223113225.63106-1-bhe@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is reported by kmemleak detector: unreferenced object 0xffffc900002a9000 (size 4096): comm "kexec", pid 14950, jiffies 4295110793 (age 373.951s) hex dump (first 32 bytes): 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............ 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 ..>............. backtrace: [<0000000016a8ef9f>] __vmalloc_node_range+0x101/0x170 [<000000002b66b6c0>] __vmalloc_node+0xb4/0x160 [<00000000ad40107d>] crash_prepare_elf64_headers+0x8e/0xcd0 [<0000000019afff23>] crash_load_segments+0x260/0x470 [<0000000019ebe95c>] bzImage64_load+0x814/0xad0 [<0000000093e16b05>] arch_kexec_kernel_image_load+0x1be/0x2a0 [<000000009ef2fc88>] kimage_file_alloc_init+0x2ec/0x5a0 [<0000000038f5a97a>] __do_sys_kexec_file_load+0x28d/0x530 [<0000000087c19992>] do_syscall_64+0x3b/0x90 [<0000000066e063a4>] entry_SYSCALL_64_after_hwframe+0x44/0xae In crash_prepare_elf64_headers(), a buffer is allocated via vmalloc() to store elf headers. While it's not freed back to system correctly when kdump kernel is reloaded or unloaded. Then memory leak is caused. Fix it by introducing x86 specific function arch_kimage_file_post_load_cleanup(), and freeing the buffer there. And also remove the incorrect elf header buffer freeing code. Before calling arch specific kexec_file loading function, the image instance has been initialized. So 'image->elf_headers' must be NULL. It doesn't make sense to free the elf header buffer in the place. Signed-off-by: Baoquan He Acked-by: Dave Young --- arch/x86/kernel/machine_kexec_64.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c index f5da4a18070a..1f0eb0eed546 100644 --- a/arch/x86/kernel/machine_kexec_64.c +++ b/arch/x86/kernel/machine_kexec_64.c @@ -374,9 +374,6 @@ void machine_kexec(struct kimage *image) #ifdef CONFIG_KEXEC_FILE void *arch_kexec_kernel_image_load(struct kimage *image) { - vfree(image->elf_headers); - image->elf_headers = NULL; - if (!image->fops || !image->fops->load) return ERR_PTR(-ENOEXEC); @@ -512,6 +509,15 @@ int arch_kexec_apply_relocations_add(struct purgatory_info *pi, (int)ELF64_R_TYPE(rel[i].r_info), value); return -ENOEXEC; } + +int arch_kimage_file_post_load_cleanup(struct kimage *image) +{ + vfree(image->elf_headers); + image->elf_headers = NULL; + image->elf_headers_sz = 0; + + return kexec_image_post_load_cleanup_default(image); +} #endif /* CONFIG_KEXEC_FILE */ static int -- 2.31.1