From nobody Mon Jun 8 07:22:03 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5314F3A5E6F; Thu, 4 Jun 2026 20:49:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780606178; cv=none; b=NEc4tC1ihvEHCsQq0S5ncK47Tlg9TT6BQ48h4AsceBlXz2xYGKdWzXQCDqXFTMxYn588C+OAmq6WTPcpj30dP+KtWGXqVPOwaaCs5FZFlS7HUwMcDrSRMivzrnEThoTv5/oGLlcW7pPg9SgWfudeZPtTpF7diyMZ+HiwTtvq2+4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780606178; c=relaxed/simple; bh=bF3F/8IC1UxGrGeYse+PT06B9e/07oxtF7xcjd6N3Qc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YFcEq/tEK7WeBkhuGvf02CZWrx7YUHzycHppM34bVFT0JxjRK5xzKzQGPPFDq2/NmmOc9rVs9CBRCyZ01IXNqCub9YUlG8/n78NnpYSJ1N056AhxCOMJI4nLHkucQvABxLltziO/gUPpx0PoE+b2tlgSi/H222R34eY4rp4urf8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dkoyl8NV; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dkoyl8NV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 703D61F00893; Thu, 4 Jun 2026 20:49:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780606177; bh=hUnG8kXEc8BYSs8ofmQrVbf2/csNKG2fsdfuTn8+ex4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=dkoyl8NVaEgpdS9sZ1J/K19+eM5K1T82b4DpSiZ0gr4zaceOrY3E8f9BYLunxaAPd yDF1LpLffgmcAtQzxnXtXUyHmHqKWO4GbgYWxpUKRMexiWLn0XM8T7psq6m33cPwam xrdABrVc0Tl3bjfCzoAoXsA2BZ6wSAwWeOoVgQurrdjayYBZ5arwwW8eQvKzlvcm2j k9K4/UlS/d6jnD1xz5ChxgV68PHeLX4B386z7b+3JlFys4xou0vkvk10vp1l9JIwUB hKdFPcvIUrtYml0KdKteR6yOTuiGxuiZvTzNm2UizxI/nggP/1+zIP4SdR1hwVttHn D+R7V9l323aYg== From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Ingo Molnar , Thomas Gleixner , James Clark , Jiri Olsa , Ian Rogers , Adrian Hunter , Clark Williams , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Arnaldo Carvalho de Melo , Anton Blanchard , sashiko-bot , "Claude Opus 4.6" Subject: [PATCH 1/4] perf tools: Guard test_bit from out-of-bounds sample CPU Date: Thu, 4 Jun 2026 17:49:16 -0300 Message-ID: <20260604204921.1707333-2-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260604204921.1707333-1-acme@kernel.org> References: <20260604204921.1707333-1-acme@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnaldo Carvalho de Melo When PERF_SAMPLE_CPU is absent from a perf.data file, sample->cpu is initialized to (u32)-1 by evsel__parse_sample(). Five call sites pass this value directly to test_bit(sample->cpu, cpu_bitmap), reading massively out of bounds past the DECLARE_BITMAP(..., MAX_NR_CPUS) allocation of 4096 bits. Add a sample->cpu >=3D MAX_NR_CPUS guard before each test_bit() call, matching the existing safe pattern in builtin-kwork.c. This catches both the (u32)-1 sentinel and any corrupted CPU value exceeding the bitmap size. Fixes: 5d67be97f890 ("perf report/annotate/script: Add option to specify a = CPU range") Cc: Anton Blanchard Reported-by: sashiko-bot Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo Acked-by: Namhyung Kim --- tools/perf/builtin-annotate.c | 3 ++- tools/perf/builtin-diff.c | 3 ++- tools/perf/builtin-report.c | 3 ++- tools/perf/builtin-sched.c | 6 ++++-- 4 files changed, 10 insertions(+), 5 deletions(-) diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c index b918f9eed5fd2441..8a0eb30eac24fdbc 100644 --- a/tools/perf/builtin-annotate.c +++ b/tools/perf/builtin-annotate.c @@ -295,7 +295,8 @@ static int process_sample_event(const struct perf_tool = *tool, goto out_put; } =20 - if (ann->cpu_list && !test_bit(sample->cpu, ann->cpu_bitmap)) + if (ann->cpu_list && (sample->cpu >=3D MAX_NR_CPUS || + !test_bit(sample->cpu, ann->cpu_bitmap))) goto out_put; =20 if (!al.filtered && diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c index 9592f44b6545bab6..9fa8e900637b0d71 100644 --- a/tools/perf/builtin-diff.c +++ b/tools/perf/builtin-diff.c @@ -416,7 +416,8 @@ static int diff__process_sample_event(const struct perf= _tool *tool, goto out; } =20 - if (cpu_list && !test_bit(sample->cpu, cpu_bitmap)) { + if (cpu_list && (sample->cpu >=3D MAX_NR_CPUS || + !test_bit(sample->cpu, cpu_bitmap))) { ret =3D 0; goto out; } diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c index 6f044c3df8937dc5..dd1309c320943ea4 100644 --- a/tools/perf/builtin-report.c +++ b/tools/perf/builtin-report.c @@ -298,7 +298,8 @@ static int process_sample_event(const struct perf_tool = *tool, if (symbol_conf.hide_unresolved && al.sym =3D=3D NULL) goto out_put; =20 - if (rep->cpu_list && !test_bit(sample->cpu, rep->cpu_bitmap)) + if (rep->cpu_list && (sample->cpu >=3D MAX_NR_CPUS || + !test_bit(sample->cpu, rep->cpu_bitmap))) goto out_put; =20 if (sort__mode =3D=3D SORT_MODE__BRANCH) { diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c index 4de2baf03c5036dc..e7bd3f331cb8e889 100644 --- a/tools/perf/builtin-sched.c +++ b/tools/perf/builtin-sched.c @@ -2192,7 +2192,8 @@ static void timehist_print_sample(struct perf_sched *= sched, char nstr[30]; u64 wait_time; =20 - if (cpu_list && !test_bit(sample->cpu, cpu_bitmap)) + if (cpu_list && (sample->cpu >=3D MAX_NR_CPUS || + !test_bit(sample->cpu, cpu_bitmap))) return; =20 timestamp__scnprintf_usec(t, tstr, sizeof(tstr)); @@ -2871,7 +2872,8 @@ static int timehist_sched_change_event(const struct p= erf_tool *tool, } =20 if (!sched->idle_hist || thread__tid(thread) =3D=3D 0) { - if (!cpu_list || test_bit(sample->cpu, cpu_bitmap)) + if (!cpu_list || (sample->cpu < MAX_NR_CPUS && + test_bit(sample->cpu, cpu_bitmap))) timehist_update_runtime_stats(tr, t, tprev); =20 if (sched->idle_hist) { --=20 2.54.0 From nobody Mon Jun 8 07:22:03 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A4973A5E6F; Thu, 4 Jun 2026 20:49:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780606182; cv=none; b=fNMcXDxDMTOeP0ymu4zdCodbmiycWEVgt6xds26cxWxwsdCZLS96ha4uupna/um/m/ciDfUIRM2SkdBvcKrBQRQmZcqKHvVwO/MOEaNvDyM7De1xfgEtqAwRUFScy1uvo+UM+MPDwEA+A7SxNhFEBuq9eO3wKKuTdK5acFXN1hs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780606182; c=relaxed/simple; bh=hVL3CNwOm4qEIBGaXnHed+ZljEbyAhdPKlmaoMqrM3g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=f87cMVYh0eROyGeVtkwdBEHNinW4ro1zFDNkiiUCcGwysMJOREifFO/cN35qt2ZC6IK2y9Qi9Q7mGg6xgrs4vE14oJr4fwl6iuBhElpnHlWbJLW8LMdnntHnOqZEz/HPTAg333VoXktpJYndvwxImXOYU4Jk4ebCFpCYLH05yaY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YkBvPtN3; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YkBvPtN3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7624E1F00898; Thu, 4 Jun 2026 20:49:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780606180; bh=vRh5S56EQv1X1h39iR1LYgRUJbiu+AHhqUAOnoJvepg=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=YkBvPtN3ojAGrXB5pqYjRHPLJtPuyCBKR1P+iOi6ckz5twl/kXFRbrvNjY/NEJAwk xOAZs8izPjVj9EXbm9PC5vGJDACWe3Ocg+sYGLCQlXa6HueMKZsUq3SXsO5NZ92bpn U5lxErkRcM/h4EWzgIt7JBUuvsOGa/6Olnv/dtoUmIp3IbeP3qsyHOG5mTI/LYlEuE wC5wYPksBkZpDpy8J+s2wG6ue4hYNG0GUQ943UFVhcPg+NP3O2yh2lritfTWZP3Um1 vQXSH2905bJw6bYLLVghkXA8hEKq2ThJm+7+KWP/jvOeGTlEmJpIRo4m9M7doLhHRM iPlm2PTT0pJxA== From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Ingo Molnar , Thomas Gleixner , James Clark , Jiri Olsa , Ian Rogers , Adrian Hunter , Clark Williams , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Arnaldo Carvalho de Melo , sashiko-bot , "Claude Opus 4.6" Subject: [PATCH 2/4] perf sched: Fix thread reference leak in latency_switch_event Date: Thu, 4 Jun 2026 17:49:17 -0300 Message-ID: <20260604204921.1707333-3-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260604204921.1707333-1-acme@kernel.org> References: <20260604204921.1707333-1-acme@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnaldo Carvalho de Melo In latency_switch_event(), after acquiring thread references for sched_out and sched_in via machine__findnew_thread(), the first add_sched_out_event() failure path does 'return -1', bypassing the out_put label that calls thread__put() on both references. The second and third add_sched_out_event() failures correctly use 'goto out_put'. Fix the first one to match. Fixes: b91fc39f4ad7 ("perf machine: Protect the machine->threads with a rwl= ock") Reported-by: sashiko-bot Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo Acked-by: Namhyung Kim --- tools/perf/builtin-sched.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c index e7bd3f331cb8e889..13b801496a01271e 100644 --- a/tools/perf/builtin-sched.c +++ b/tools/perf/builtin-sched.c @@ -1180,7 +1180,7 @@ static int latency_switch_event(struct perf_sched *sc= hed, } } if (add_sched_out_event(out_events, prev_state, timestamp)) - return -1; + goto out_put; =20 in_events =3D thread_atoms_search(&sched->atom_root, sched_in, &sched->cm= p_pid); if (!in_events) { --=20 2.54.0 From nobody Mon Jun 8 07:22:03 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E459A4C6F13; Thu, 4 Jun 2026 20:49:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780606185; cv=none; b=EMyIHhO43kiVpJ7imDZWqmUuUx6zGP59jZckKAeYtoUaZl+xEH9NhjfvAD49ueBcGYyA5sltT3vtJWAvbHAigS6ROgVXyqOGMY0l4NJwOFO+/LrbV71M2CHs7Ch/7uX1IiCZ5xeVlchn7qAnEmBqL21aAvZlxmZALm8R0B0/zmk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780606185; c=relaxed/simple; bh=UCQpoZtRZQix/YorHPv3+3WJF0dhBiq66RD+C0xocqY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=sPd/TiSWYYhha6ShCrpbEaYudP2TRfHeWe0ltTp/g8oj/6dBnw9DQlOw+hG/fZnbZZSAvDnn7MXJ94dM19VIiYjRyeI47sV56eOArNXJ+9U9B46iyxAicxQ3meRJQx4j2W/i18iRCFbSsbcg9Npx00J2Zmo6TK5ahkm3fH1kIqc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ajHCCxK+; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ajHCCxK+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 47EDA1F00893; Thu, 4 Jun 2026 20:49:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780606184; bh=uDdZdq443dw1xqiU/tHBf+lc30Tzb+J6wcTr3uCO5ls=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=ajHCCxK+UzciRNqbD6hKy97J8FjZ11DEM2Kywn8ooj01D3keXAHE+r7Oc9WLdU6wg fnBH2ncbO3cYCh4URpYD5Fb2OWOVcxFMIzOXQv+8Va4zI+bazG6K+vMnOMHMcdfr53 XWD4I+QsA1lgx7eHQII2Glmdnyq6W5/0fpF7rdTZjKGZeNG5SWGBZG5mVHZOVhfxf3 ZRCxNGuS4seAZIjNrS6sEhtQurtwhxnHVW8p1YQlf24VR3v6eJkA29Iwc7haWlb8YK kBr4f36JoyLI9Xoddd4N8CaSbdqc5FV3X6wplMCJ25038LEmL5QM04BSVqqHIVafdU uHdZm8gATdC2A== From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Ingo Molnar , Thomas Gleixner , James Clark , Jiri Olsa , Ian Rogers , Adrian Hunter , Clark Williams , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Arnaldo Carvalho de Melo , sashiko-bot , "Claude Opus 4.6" Subject: [PATCH 3/4] perf sched: Fix NULL dereference in latency_runtime_event Date: Thu, 4 Jun 2026 17:49:18 -0300 Message-ID: <20260604204921.1707333-4-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260604204921.1707333-1-acme@kernel.org> References: <20260604204921.1707333-1-acme@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Arnaldo Carvalho de Melo latency_runtime_event() passes the return value of machine__findnew_thread() directly to thread_atoms_search() at line 1216, before checking for NULL at line 1220. thread_atoms_search() calls pid_cmp() which dereferences the thread pointer via thread__tid(), causing a NULL pointer dereference if the allocation fails. All other callers of thread_atoms_search() in this file (latency_switch_event, latency_wakeup_event, latency_migrate_task_event) correctly check for NULL first. Move the atoms assignment after the NULL check to match the pattern used by the other callers. Fixes: b91fc39f4ad7 ("perf machine: Protect the machine->threads with a rwl= ock") Reported-by: sashiko-bot Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo Acked-by: Namhyung Kim --- tools/perf/builtin-sched.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c index 13b801496a01271e..36da451447b5e59f 100644 --- a/tools/perf/builtin-sched.c +++ b/tools/perf/builtin-sched.c @@ -1213,13 +1213,15 @@ static int latency_runtime_event(struct perf_sched = *sched, const u32 pid =3D perf_sample__intval(sample, "pid"); const u64 runtime =3D perf_sample__intval(sample, "runtime"); struct thread *thread =3D machine__findnew_thread(machine, -1, pid); - struct work_atoms *atoms =3D thread_atoms_search(&sched->atom_root, threa= d, &sched->cmp_pid); + struct work_atoms *atoms; u64 timestamp =3D sample->time; int cpu =3D sample->cpu, err =3D -1; =20 if (thread =3D=3D NULL) return -1; =20 + atoms =3D thread_atoms_search(&sched->atom_root, thread, &sched->cmp_pid); + /* perf.data is untrusted input =E2=80=94 CPU may be absent or corrupted = */ if (cpu >=3D MAX_CPUS || cpu < 0) { pr_warning("WARNING: at offset %#" PRIx64 ": out-of-bound sample CPU %d,= skipping sample\n", --=20 2.54.0 From nobody Mon Jun 8 07:22:03 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 79F1D4C9553; Thu, 4 Jun 2026 20:49:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780606189; cv=none; b=Mrd2QMT8q3t2WoZ5dj3I6gvnpH+Iag/yYe+JbbDe1Q16iiqV2o8BEfXLYWZGb7h88XhIa0vS7kROEbcUFqGWRlGb/6vwxfHEnRYZkJo3nf+K/nRjn0J7FFlBlj3Vb7jHtZg9GKuOGKT0ft/hMSjdVMcAbTdt4hPnVVdqa2ho1WE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780606189; c=relaxed/simple; bh=2Rd2MxgW6mdsvreVToz2brln03GsPRHIeYWxddl9bWc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=oBGuQkBZG2YL8VP8IeWhKcPTvNalhDd9ByA6Tm4posPnDkBOygYZ4ZasQnZvl52KAclcpWxBJLb7RIMCCQU5v/jDYV7N/67PU6UEAkqojmJg/1BaOlpOYms1CTKR6mryWUkDp5QhfOskt018f9b1vldeoRCql7lDH/J5hFqr02o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aDV3vm71; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aDV3vm71" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19AF01F00898; Thu, 4 Jun 2026 20:49:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780606188; bh=Ospe3Hydc6JnSKzD18hwPkawOnG8Qo0XDbVu36cURKQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=aDV3vm71bQcWHCcDkBT8oWMMKr39D5H0s2nFIBsmcayJYaxAOAba83b2yb6bcrwkS znbXUrsyJO+FfDW8/Ad8IHOyWoNyPkwNdaxPnGnZejhnekXOPFW/4eCe/JxgCZNtZ+ tFcJBOXzFgyqFW5KXHMzQ/25boVRyaZcDBgvXci1AsN1zjvSVSpzd2LWeVxPT+ZrSA C8QramQ7SXWKeSUZVkXA6XA4/8+aiOkQ2Jy7rhPeviFp66KGcJYj3ACRb4UnFSSf9W RPXKAOEtxQ2RUZgXLy6bc0onMo0eIYlxqZXvQXRTaRlwQiEUvJH0y64TrsgIS4Gjj4 aisqisV9Su6Tw== From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Ingo Molnar , Thomas Gleixner , James Clark , Jiri Olsa , Ian Rogers , Adrian Hunter , Clark Williams , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Arnaldo Carvalho de Melo , sashiko-bot , "Claude Opus 4.6" Subject: [PATCH 4/4] perf sched: Fix comp_cpus heap overflow with cross-machine recordings Date: Thu, 4 Jun 2026 17:49:19 -0300 Message-ID: <20260604204921.1707333-5-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260604204921.1707333-1-acme@kernel.org> References: <20260604204921.1707333-1-acme@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Arnaldo Carvalho de Melo setup_map_cpus() allocates comp_cpus based on sysconf(_SC_NPROCESSORS_CONF), the host machine's CPU count. But map_switch_event() indexes comp_cpus using cpus_nr derived from bitmap_weight(comp_cpus_mask, MAX_CPUS), where comp_cpus_mask is declared as DECLARE_BITMAP(..., MAX_CPUS) with MAX_CPUS=3D4096. When analyzing a perf.data recording from a machine with more CPUs than the analysis host (e.g. 128-CPU server recording analyzed on an 8-CPU laptop), cpus_nr exceeds the allocation size, causing a heap buffer overflow. Also fix a type mismatch: comp_cpus is 'struct perf_cpu *' (2 bytes per element) but was allocated with sizeof(int) (4 bytes per element). Allocate comp_cpus with MAX_CPUS entries using the correct element size, matching the comp_cpus_mask bitmap bounds. Remove the sysconf(_SC_NPROCESSORS_CONF) initialization of max_cpu =E2=80=94 its only consumer was the comp_cpus allocation, and max_cpu is dynamically updated from the recording's events during processing. Fix the non-compact path to use max_cpu.cpu + 1 as cpus_nr, converting from 0-based index to count =E2=80=94 sysconf() returned a count which masked this off-by-one. Fixes: 99623c628f54 ("perf sched: Add compact display option") Reported-by: sashiko-bot Cc: Jiri Olsa Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo Acked-by: Namhyung Kim --- tools/perf/builtin-sched.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c index 36da451447b5e59f..4aa7833cae6e36b8 100644 --- a/tools/perf/builtin-sched.c +++ b/tools/perf/builtin-sched.c @@ -1670,7 +1670,7 @@ static int map_switch_event(struct perf_sched *sched,= struct perf_sample *sampl new_cpu =3D true; } } else - cpus_nr =3D sched->max_cpu.cpu; + cpus_nr =3D sched->max_cpu.cpu + 1; =20 timestamp0 =3D sched->cpu_last_switched[this_cpu.cpu]; sched->cpu_last_switched[this_cpu.cpu] =3D timestamp; @@ -3573,10 +3573,8 @@ static int perf_sched__lat(struct perf_sched *sched) =20 static int setup_map_cpus(struct perf_sched *sched) { - sched->max_cpu.cpu =3D sysconf(_SC_NPROCESSORS_CONF); - if (sched->map.comp) { - sched->map.comp_cpus =3D calloc(sched->max_cpu.cpu, sizeof(int)); + sched->map.comp_cpus =3D calloc(MAX_CPUS, sizeof(*sched->map.comp_cpus)); if (!sched->map.comp_cpus) return -1; } --=20 2.54.0