Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2183441iof; Tue, 7 Jun 2022 22:28:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJySyc/ir33wC2stF1BCj9MT/Fe9YBAeoGPu4cThYVeoWp0abucv+VVOiSzGN23Y0Mr5aFCX X-Received: by 2002:a17:90b:4d90:b0:1e8:951b:40c8 with SMTP id oj16-20020a17090b4d9000b001e8951b40c8mr11030372pjb.130.1654666092521; Tue, 07 Jun 2022 22:28:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654666092; cv=none; d=google.com; s=arc-20160816; b=ey4bMYN6BteaVw1DQoDD8BF9LvaW93/UVOqtO9OBRMOGVhvaQfegyLQ131+joD42Mk w0UoIKoQALVURPEI84STSEOd+xExTn3VHYqbvFAsd/kGhKh3DmuW9Le3uUlPnXuKy9eI q/xU1OtYZjadex7PK8F+VyqJNomrovlqUfBSwDQgwCtKTSGRckoUeIrtGq9CZIZlQMhs zxvJOKXypZJcOLh6+m2dNCV7k+MERJADfbmIhz4XGRv9oTSBLbx0CNmrgf22CkjKVYCN 9EhBAyQVhLbMBTaOkkFnFB7BW8cj7C6KLFUBUe+Lj/a1HKzuH8O90rBc/CJohnXz45f3 gszw== 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=/Sa0G63rtlOMCOpwYIhv6ykKzunMTK+5PJR7FjHCdGs=; b=nqWWLqA5+IKw7tCGJky21SRSnfnm54JsTn/tKThvsoSh8CTbMM6TTRKAJ4yz+kIVma /0L77CGsze7nJ2evUfe4xw7mhRpPrqIjOftt911UXIn8vWyOWjZDTQgQO9m1+b0hPhxG lNAL96o0zCrVl/NQley2QE+ktLJJs4joENsrdSv2BJ63c1yeq+kA3oJyxVYj94mfCi5Y OAfpZrlR2OgS5vhLq6aamhxR0lkRJ63SHjM5FuXh9a04QwiMGr/Gg8j5Qfjy4mTYBfO3 KaRUVa6ut8JgeKoxOLtxzhS6/OxqVwc3aE2kGw+MIQT4BEc9ievFgaTQiUixSkaT1XYF 8rQg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=VaCBnSe5; 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 9-20020a630009000000b003fccc4a7452si26470913pga.132.2022.06.07.22.28.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jun 2022 22:28:12 -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=VaCBnSe5; 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 D991D47B49F; Tue, 7 Jun 2022 21:54:37 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359798AbiFGUZj (ORCPT + 99 others); Tue, 7 Jun 2022 16:25:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355928AbiFGTe0 (ORCPT ); Tue, 7 Jun 2022 15:34:26 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C2D9A1AA3EA; Tue, 7 Jun 2022 11:13:13 -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 ams.source.kernel.org (Postfix) with ESMTPS id 134C9B80B66; Tue, 7 Jun 2022 18:13:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7DC62C385A2; Tue, 7 Jun 2022 18:13:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654625590; bh=TWv2+8rZsfun2MIc+lMfnFiyX+f1Qt4sfk54CPZIoZE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VaCBnSe5aGIHpmmy52+f9PnWUvP5+PtzGxJDwj6e1WSUPM3nZ7IR7uscsxkw594st MEGs92o/TvJx74M0I5zDo6qFzvf95tQYWgTugEcKgaEqWJ9GAnAGkGCDU/x3TrmSKP tfOzuwbpuIDqBxcTzwBiR4v2o7bDqv29nClMoXkU= 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.17 036/772] x86/kexec: fix memory leak of elf header buffer Date: Tue, 7 Jun 2022 18:53:48 +0200 Message-Id: <20220607164950.087234411@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220607164948.980838585@linuxfoundation.org> References: <20220607164948.980838585@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 @@ -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 @@ 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