[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20231205032709.9525-1-dinghao.liu@zju.edu.cn>
Date: Tue, 5 Dec 2023 11:27:09 +0800
From: Dinghao Liu <dinghao.liu@....edu.cn>
To: dinghao.liu@....edu.cn
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>,
Colin Ian King <colin.i.king@...il.com>,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH] perf/x86/uncore: fix a potential double-free in uncore_type_init
When kzalloc for pmus[i].boxes fails, we should clean up pmus
to prevent memleak. However, when kzalloc for attr_group fails,
pmus has been assigned to type->pmus, and freeing will be done
later on by the callers. The chain is: uncore_type_init ->
uncore_types_init -> uncore_pci_init -> uncore_types_exit ->
uncore_type_exit. Therefore, freeing pmus in uncore_type_init
may cause a double-free. Fix this by setting type->pmus to
NULL after kfree.
Fixes: 629eb703d3e4 ("perf/x86/intel/uncore: Fix memory leaks on allocation failures")
Signed-off-by: Dinghao Liu <dinghao.liu@....edu.cn>
---
arch/x86/events/intel/uncore.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
index 01023aa5125b..d80445a24011 100644
--- a/arch/x86/events/intel/uncore.c
+++ b/arch/x86/events/intel/uncore.c
@@ -1041,6 +1041,7 @@ static int __init uncore_type_init(struct intel_uncore_type *type, bool setid)
for (i = 0; i < type->num_boxes; i++)
kfree(pmus[i].boxes);
kfree(pmus);
+ type->pmus = NULL;
return -ENOMEM;
}
--
2.17.1
Powered by blists - more mailing lists