Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2114227iof; Tue, 7 Jun 2022 20:12:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzVYqE7BA2PNzI/5+TvIDhGSG1JRv0BoYvtyQlutp9M2N6LSXpQ9UP8/ik7kBwc3prWEAmn X-Received: by 2002:a17:903:44d:b0:167:6c02:3372 with SMTP id iw13-20020a170903044d00b001676c023372mr17628267plb.45.1654657960770; Tue, 07 Jun 2022 20:12:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654657960; cv=none; d=google.com; s=arc-20160816; b=tTPK9YCI5/71XFzPN81qqbdcEalSrSVEg5oJ/UtYJZwWcD4HgpTUZY/t0xCk3Bd+Qn BEzKgGejDWggBY84hQNIufdBl+Rko4BXNJ8SbA/m4iZxjbMfAuyQDmvMURfbZnxVZlce Fha7lb8QwBwbDERgY91LUjrW2SltQeRENShR1RwQPeCsup+Oe1q01bbUMTcnOhiIHBpH fS6anH4d5tn4aWlQKMXrMQ9Gcg26+xnWwmCqswv6zdn1aqdxM0CBQ4ddich29E+qoLBE a4SvsMyIGaJ/59QBy4ZzQQAMVTsYHPP9GS3gH1KdBOzk8+bLFGUTncqBsSIxL4jlb20s hREQ== 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 :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=PkpMi4imX+noIkLWIGULwr0KqyerzLF5CjVqprRECo4=; b=gqVw2TDldjhFPIgK93tojHCRyPw6r8yKt81RrmDv37epmP2Vgk1BMcTYbQZutwK6+o n3FYxBBqToAecaY5BZR5DUJGVWcikn5Bm4TGFC1jXPqIHLsAJVxsUsg1IzVbuGik1qxA /pdY7iU23LVivM3Sc+ex/hno/yE2S0wQGkHjVmOmfp8AFc0pAhDO5QPYO1KlPhtzh4+7 J51gf75R4zrWW4wg0PHxbcT4n3eb+JS+rzxeBDHWZIOoZUdVdnxL1QsLXni+oWNGngz6 V4+xyJZ7x1QTbTEvJhBedePlIjNP20ZlHbq++tr0wJDhOqOZpqGlCQBFpSemxr51T6fj IE9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=CSJv52Ph; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id j3-20020a170903028300b001674d42aef2si24645390plr.411.2022.06.07.20.12.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jun 2022 20:12:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=CSJv52Ph; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id AA046EAD39; Tue, 7 Jun 2022 19:17:09 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1382722AbiFGV7f (ORCPT + 99 others); Tue, 7 Jun 2022 17:59:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49914 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1379272AbiFGVCS (ORCPT ); Tue, 7 Jun 2022 17:02:18 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 22D8F41FBF; Tue, 7 Jun 2022 11:47:17 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B389361295; Tue, 7 Jun 2022 18:47:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD027C385A2; Tue, 7 Jun 2022 18:47:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654627636; bh=pF3h+0KVTBt6CIL4yFsTZkcuC4lHFPVqrqtLLicmaJg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CSJv52Ph7EI9WQFO3bqSxaGvOOqYtbiqsKXQ3PVZkB68HMzIS444ErxhdyqVloHMx v9gCnBDaQ04a8ydpmixQEz4QVuFe+hAMd8HEGiteryB6EEEDahi1uGxwvu2P6uc6YX QNY3l97FpIpAiap63aM6tc/IVJ+vXJAPupiy7yXE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Baoquan He , Dave Young , Andrew Morton Subject: [PATCH 5.18 039/879] x86/kexec: fix memory leak of elf header buffer Date: Tue, 7 Jun 2022 18:52:37 +0200 Message-Id: <20220607165003.812709309@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220607165002.659942637@linuxfoundation.org> References: <20220607165002.659942637@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 From: Baoquan He commit b3e34a47f98974d0844444c5121aaff123004e57 upstream. 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. Three different people have reported three bugs about the memory leak on x86_64 inside Redhat. Link: https://lkml.kernel.org/r/20220223113225.63106-2-bhe@redhat.com Signed-off-by: Baoquan He Acked-by: Dave Young Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- arch/x86/kernel/machine_kexec_64.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) --- a/arch/x86/kernel/machine_kexec_64.c +++ b/arch/x86/kernel/machine_kexec_64.c @@ -376,9 +376,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); @@ -514,6 +511,15 @@ overflow: (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