From nobody Mon Jun 8 07:21:50 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 323673D9051; Thu, 4 Jun 2026 20:11:34 +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=1780603897; cv=none; b=DPURR2At7+vC1TILR9xtiRKYXXGqzGC5NcVU8xj5beeHQFQC/PzftNv3gG3usSrSwzBB95UB18/uR2DcGs0qI4eSJNypG/bqZx8tutVw7GPiDD02veTjEGI/qywTLYJ6d7TQBKOyfHloLUYmCVd+2xzvZukfvR6bhD5Uo4z82Iw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780603897; c=relaxed/simple; bh=bF3F/8IC1UxGrGeYse+PT06B9e/07oxtF7xcjd6N3Qc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LuOqvakjtlE7aXdOJf4xAhZTS3i7y3DerPxVudh3+wdr8m5pQGRD1HxCvQ8ofmzT3BZkURLL1RW+uiXlm9i2NMoiX5K4V3cE9UD77o3uP7uvLBRTvBq7nBtbDUdDKq/J5Tdlyeww+x0TcjIaA/1wQ16oOmAk17wGxg9Bs5U7x5o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oUUuKpCK; 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="oUUuKpCK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B9B81F00898; Thu, 4 Jun 2026 20:11:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780603894; bh=hUnG8kXEc8BYSs8ofmQrVbf2/csNKG2fsdfuTn8+ex4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=oUUuKpCKJCL78EyEnrcUGrpr1JPOfcdjOHinhmBjKAsfG7Pj6Si7f+WNbs5d+Cp/t BJ9cgEqFHlFv8xCdp8HtI9rVV8LPG0J9c6g7eOkcgBpdkvKcDte5DJFzzGTL2UjBn/ 5NlkUz3yPfWQgCDpXBr31K8r+6tJ00Rt2z9xy/PfypZXVzq09DVRzX0FE8K6ZiUFYJ Zd4ULOezq2VZBSzlgoRZnsvpJiL8hbReWk7gBy/y3fmb1wIq58fhmvHeUaQNyiyAfk hubnJL8BdttfEBEoiAU5KIqZ8cV2SQV8quuSbUiYABGIVmMQI8fdb8nknsiDZLZJdQ FdrX8tX8VmD7Q== 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:11:13 -0300 Message-ID: <20260604201119.1702338-2-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260604201119.1702338-1-acme@kernel.org> References: <20260604201119.1702338-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 --- 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:21:50 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 B451A3DA5C3; Thu, 4 Jun 2026 20:11:38 +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=1780603901; cv=none; b=L3orvLZxdO20uE7A7080YTYR02XJJi4LVWMxoSLyi2aPepnoxJd6SxQRfZawdwUJjcYisdLfBaSHT22m2TtQu0B92hR3T0UErxmMg0agOU/Xz8nfEmExxNjTcTeCUn12EWJ379C1ak6UdPvhoMU+oHNL+O8uBQHGX0ZJs6X+Wtg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780603901; c=relaxed/simple; bh=hVL3CNwOm4qEIBGaXnHed+ZljEbyAhdPKlmaoMqrM3g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Jr2PeR3vnhHWEjfj6GNAc9CARjg8pH5KT0cUiRcsKkiqza4TuSvNon8j9xHIv+vfvCEH5MKM4QR/wRKx4BdgdX7eCVkgRTeVgkM955aePIzvdHuQ8EdK1Al/SMWB1v3lfCBA1IluwU2ELENzD1IEGyfYMAV7DPncy9FssyOlND4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MbzSktzR; 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="MbzSktzR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1F1631F00893; Thu, 4 Jun 2026 20:11:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780603898; bh=vRh5S56EQv1X1h39iR1LYgRUJbiu+AHhqUAOnoJvepg=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=MbzSktzRyWCS0JqU6fSU9RKMqfq+mnWa/ybzGElA7cv3iQGrIo42RITInr/fkiw/2 2mukSAZLptBlVOxNNzGXWIHR9LKlqaJtKZpFimbKoJOPLRV11M6Uh4Jbd68AAMyRjM xUEoW/DZbrUbdIz43VFQaMdFYbQl/fcHYRUU/qXP019mqqI5rJBMfFfUqZOLoam29I Sy3ZvmoAhQ6ZZZSFYtVHI9CNn1LH9a9hgAplFzSB46Z9zpICRpO3rcIBtTRPnN6QE1 3r0XxkxRGrqOKqq7C6SS8+b/I3eRrK7QN0UfORcHPJ9E7J2KiER10BOO/Upnxh5FTT BMcJPa/Oi2aNQ== 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:11:14 -0300 Message-ID: <20260604201119.1702338-3-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260604201119.1702338-1-acme@kernel.org> References: <20260604201119.1702338-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 --- 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:21:50 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 B7A923DA5AC; Thu, 4 Jun 2026 20:11:42 +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=1780603905; cv=none; b=UKK9XSQf0IfzeHGPlsOoL2rFOVDDWmVqnvs01n6lSAKcejqxtiNK/LUfKkER9Q+IuQ+O5Y0vQ+KSpXmNzZC92eWxqxPtihkb8gVY46DO0ItXP225Yo9VvQyrwhmUlIr8AwceFxAtXpNOolLWZuD1ojJr0uu799Xh9nexbmhu/2k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780603905; 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=QvlMsIncbSp6fDvWtDRcathcouKlKfHiA3v0ESOntgKw8/r8pXwzoQcPzcQuQCHFUPlcFDFl5+5UDYTUGjqGPXDk9l2lkfz5UORUp+o/BySqb8e7LYCPt5GczLM6UszDzyVMArl+GQDDCuYJ11QdNGZdjdyrsDh0s1KG+Yy90Tg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GrWl1mLT; 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="GrWl1mLT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E31EA1F00898; Thu, 4 Jun 2026 20:11:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780603902; bh=uDdZdq443dw1xqiU/tHBf+lc30Tzb+J6wcTr3uCO5ls=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=GrWl1mLT6RNVYix2IL67065ZVbgoB8EEyersxhdMw8uONzmrsfmcHHgsRf5+lLggV 9Fhdrib1FQxKbvFg/gP3PHqA7A6DX8bMW07r4+zRDy4pCmJ+KIg94lGuOWi/8hf+pz WqDL99o1EhEEbK3LBNHElZWIUvrex64eTWE9P3+WtsFwpC2I6vTMN65RhZh9C+hbpb NqBoQ2rJi8Y3iPePx4d6/Dg76TVLb0AhWAV/2Ni6v6suz86eNTWTG6JWDERz8BTSfO 3qUK7j9UZ1nt+GI80R5KJ2SsKIfq2lA3YRY3KCezwNsgS133D69JFM91LCh6OOMgaG 4VAcLJ7sn2WnA== 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:11:15 -0300 Message-ID: <20260604201119.1702338-4-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260604201119.1702338-1-acme@kernel.org> References: <20260604201119.1702338-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 --- 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:21:50 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 4F5713DD516; Thu, 4 Jun 2026 20:11:46 +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=1780603909; cv=none; b=QufBGpvVcdT1MWV2sXVYJ/LpFIg/YvkDDv0oFXw3tDO+NWVtyDhPYXQk+X6Lu8oIw+YWd+m+zYOglS+JKfA156PP9J/ral1nLO3N5CZaprISSUpmMmv3waoYargvaSxRp/0FAXWyimDa95ehy16GglekDJNgyi+p6vJEzzlVNL8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780603909; c=relaxed/simple; bh=pY8JER7xP2Hc+mwd7u9XFPM0lsumhggPajxIp/IvA3o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=HRs+k0Or7sV0hQI3bNSDj5Y1zqM0mwpj8TqRTUjkaXoTaAPuc5RnNYbY92+6GT4S3rhcFX3DK1P1+o1RSj9e3i8iROIfUpjXRDLOZM2QQVTMAtAKAbKGV1Q8H6qP/BvMnuaOlsI4dY79BpLnnyWlOD9NWWYrUyvq0ylfQNknb1k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Wus6LPz4; 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="Wus6LPz4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B2A761F00893; Thu, 4 Jun 2026 20:11:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780603906; bh=+rtWvq+W9pQGpnq8lH+dygwF8usaybX8YWuerV5k8R0=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Wus6LPz4ZN3IptlRmV/YWqPVYVUDaBFNth+XVWLr9FFGm+iiIr9tRnhkoTL5LrkJN zP2ZK/wfSGE4m2GI7eHxviwKnBN/OzPdSPOMlRAslF0wRBtbbEhIZX//cWYbk3SGcq wo1sCE+WykmDcOIrOdE7dPCje+f24J/KjX5cUlRxGfJibA24X1c6ZdvUPbw00zOaBN YPgfAWiVCwrPk3OfQ4aSXvgRUWtSKzXPM+ShuLPHGgQeqNkpA4Kj9/ar0lHTd7oJ/O 2AFSQch3hgXiI1fD++si3z/kRVepcz88HpjvctPWpVpohkAYO9C8irIGi/jFWXta5E Jyl6AfZnjAZkg== 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:11:16 -0300 Message-ID: <20260604201119.1702338-5-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260604201119.1702338-1-acme@kernel.org> References: <20260604201119.1702338-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 it was on= ly used for the comp_cpus allocation, and max_cpu is dynamically updated from the recording's events during processing. 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 --- tools/perf/builtin-sched.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c index 36da451447b5e59f..80e42536400a91c2 100644 --- a/tools/perf/builtin-sched.c +++ b/tools/perf/builtin-sched.c @@ -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