From nobody Thu Jun 25 01:53:41 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 86577332909; Wed, 10 Jun 2026 16:52:21 +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=1781110343; cv=none; b=UlVbrb6hQZarXdldMm1oJu9pcyRYQCKiXMlukmVc9Zj9IXbeUzya8MsHToRr0mtlEhGwK3ORGzdh/CpNK9f7etFSR/mwSfMBylALI3N1hgMxl5s96YbweUJfnxwdZmoyeWI3fgFVQgTCPuCN2hpLW/B9zpwfXTbGfEjRj+Px+R4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781110343; c=relaxed/simple; bh=VC6q+mtq8KwC5Y4PLY6wDdpjHfEtE2CGjR6ZMYxBHMs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=CJkhrZqXHIeI62LSHqQkm+f3QMfKH8sjyinWSsh3lDrHzXgFYR8irf8PGQCVmAsIO/T2q3lbqsIH04bi8TtFR3r8fV/+bmkweDHVfuf7DoCyIQOmonBZSbrMPZ9/+ioblM2loLkjcWEFVgw9kb0wesaC4fFOHuMeTiNz91Bfhdw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Y4nVxycl; 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="Y4nVxycl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 77D731F00898; Wed, 10 Jun 2026 16:52:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781110341; bh=HnEEYaaAEIVtR7qYXVTM1b0f6ONnauIaMoMKazEsRPc=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Y4nVxyclrQLTnDhccHX3PcgeCDCssIGRXURR60HenLlctDp2ibWBKpGrExzYNC+qD 0k44Yvqg9IKUTlQlnL+uVb+i/wYynrjHofQvDvBWrBhOanlu1OO+pgJxxPjY2vw8jh E79XlzxYoqSmcQ3k42cWuLfKDrLkLTHwRJoQXSr1jdgiI2OdFrbA+yGjcBNZdV6Dg+ QhRNngl9SWlMbPBxKkRqS5W5G3uLMA6wPRB3L8k4pv03KgDWXyxoAtgoGTpnX3CHZK R1RbYCjNpHixX6ZMR3WXxs642hg4OiN+3G3F1UZ/tzg51q9bu2DE6EmkrELY/9ww1h k4AVIaxqUmnAg== 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 , Don Zickus , "Claude Opus 4.6" Subject: [PATCH 01/11] perf tools: Fix get_max_num() size_t underflow on empty sysfs file Date: Wed, 10 Jun 2026 13:51:55 -0300 Message-ID: <20260610165207.2077258-2-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260610165207.2077258-1-acme@kernel.org> References: <20260610165207.2077258-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 get_max_num() reads a sysfs file (cpu/possible, cpu/present, or node/possible) and scans backward from the end to find the last number. If the file is empty, filename__read_str() returns num =3D=3D 0. The loop `while (--num)` decrements the size_t from 0 to SIZE_MAX, reading backward across the heap until a comma or hyphen is found or unmapped memory is hit. Add an early return for empty files before the backward scan. Fixes: 7780c25bae59fd04 ("perf tools: Allow ability to map cpus to nodes ea= sily") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Don Zickus Cc: Ian Rogers Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/cpumap.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/tools/perf/util/cpumap.c b/tools/perf/util/cpumap.c index 21fa781b03cc7409..1fab00ec4a59a0c7 100644 --- a/tools/perf/util/cpumap.c +++ b/tools/perf/util/cpumap.c @@ -448,6 +448,12 @@ static int get_max_num(char *path, int *max) =20 buf[num] =3D '\0'; =20 + /* empty file =E2=80=94 nothing to parse */ + if (num =3D=3D 0) { + err =3D -1; + goto out; + } + /* start on the right, to find highest node num */ while (--num) { if ((buf[num] =3D=3D ',') || (buf[num] =3D=3D '-')) { --=20 2.54.0 From nobody Thu Jun 25 01:53:41 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 0232A3264F1; Wed, 10 Jun 2026 16:52:26 +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=1781110348; cv=none; b=sm9Z3oPtaNBHM0n55/z4h2U3faE9mmcDyxrCWu5RyPFcXG3/tt1ggVB54T9sTguTd1BK2VJicAlZlfFDitMbZx31st8SzUIWttmsj5IznI3kSu86ba0dhEs8tlBxa0+BX57JqbaedYBSQ+XrTqhJrXQWwcSRyQlObqshFwVRDRQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781110348; c=relaxed/simple; bh=6E0jlwjo8dDiP2EqUUKHlNjQnr9XYwg9NEpdtvivBA0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=I8SPij6/SuU8IxoqZux9dsps+a/lgWEK4e4ciU04a9gCxGXQtbNrVVMpZXYpPIUqtCU6LGWdSXdfKEasH5NsLHMVk3R48OlUFnYumyHGmDlbZe3ybHApa7zIqB7sAsB7pRFqW0D0RIcsCf5DgSMEYbISy9Ie5HYaH9ABt5gZCpk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MrVpf0R3; 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="MrVpf0R3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CCF361F00893; Wed, 10 Jun 2026 16:52:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781110346; bh=k9BqWutRvw0+RkzNORm405vrBwlivKjfA199rTg8lc0=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=MrVpf0R3MSKAEU8VUWd+c2lJDVibERHTvt74akEsXr3H4mu8PEeXz1uaSlMqpZGq0 BQJzdVPFQINFLYN0O3w00enDVC2n3KF/6QNeLwdvwbLzD13lzQqwqsOU1EGbbJVjWe NOziHpyzM0Id4RdODEBcJCjTusKvLkQ+gCCcqEmX9j3ZY/UKhIKZr+D7L9R5raXCyv HPQ9UITMDN1POYJfgUx/t8TQUlc6sXhrJA4+tnCPYNtHZh2Qn13ZwHtTcSDBNnrJ4f 1qwADCEFgotOxSrwaE44EPfcjz83N7pY3COY3ysa/dzPCszCcUa3IR93EGjpoW+f7i 2MP/OVi2C2HOQ== 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 02/11] perf tools: Use scnprintf() in cpu_map__snprint() to prevent overflow Date: Wed, 10 Jun 2026 13:51:56 -0300 Message-ID: <20260610165207.2077258-3-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260610165207.2077258-1-acme@kernel.org> References: <20260610165207.2077258-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 cpu_map__snprint() accumulates snprintf() return values in ret. snprintf() returns the number of characters that *would have been written* on truncation, not the actual count. When a fragmented CPU list exceeds the buffer, ret grows past size, causing `size - ret` to underflow (both are size_t), and subsequent snprintf() calls write past the end of the caller's stack buffer. Switch to scnprintf() which returns the actual number of characters written, making ret accumulation safe by construction. Fixes: a24020e6b7cf6eb8 ("perf tools: Change cpu_map__fprintf output") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Jiri Olsa Cc: Ian Rogers Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/cpumap.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/tools/perf/util/cpumap.c b/tools/perf/util/cpumap.c index 1fab00ec4a59a0c7..23ebe9b97f8e58af 100644 --- a/tools/perf/util/cpumap.c +++ b/tools/perf/util/cpumap.c @@ -692,21 +692,21 @@ size_t cpu_map__snprint(struct perf_cpu_map *map, cha= r *buf, size_t size) if (start =3D=3D -1) { start =3D i; if (last) { - ret +=3D snprintf(buf + ret, size - ret, - "%s%d", COMMA, - perf_cpu_map__cpu(map, i).cpu); + ret +=3D scnprintf(buf + ret, size - ret, + "%s%d", COMMA, + perf_cpu_map__cpu(map, i).cpu); } } else if (((i - start) !=3D (cpu.cpu - perf_cpu_map__cpu(map, start).cp= u)) || last) { int end =3D i - 1; =20 if (start =3D=3D end) { - ret +=3D snprintf(buf + ret, size - ret, - "%s%d", COMMA, - perf_cpu_map__cpu(map, start).cpu); + ret +=3D scnprintf(buf + ret, size - ret, + "%s%d", COMMA, + perf_cpu_map__cpu(map, start).cpu); } else { - ret +=3D snprintf(buf + ret, size - ret, - "%s%d-%d", COMMA, - perf_cpu_map__cpu(map, start).cpu, perf_cpu_map__cpu(map, end).cpu); + ret +=3D scnprintf(buf + ret, size - ret, + "%s%d-%d", COMMA, + perf_cpu_map__cpu(map, start).cpu, perf_cpu_map__cpu(map, end).cpu); } first =3D false; start =3D i; --=20 2.54.0 From nobody Thu Jun 25 01:53:41 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 EA194344DAD; Wed, 10 Jun 2026 16:52:32 +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=1781110355; cv=none; b=a5LChmnBeo5ii2SpF06ZcCRu5b4mCl/z897InijwDWAKUWSwfz0B2hn1bDW11ExAo+qWqnoub7j4F4e5lKsZSJl3TrzsA2CrNOg6agneUp54vTutxWLHetedZa+rjPrxqbBdPsW67vh3T6L5+PPYCnHZKRJ+lWAbio/45LN7MwY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781110355; c=relaxed/simple; bh=EXMhfvwLLw040xfsGolKK1QjRG2FMg6rWYFfl1PZy6E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hvwb9AUVgkZc1szWLDP8u0O7H/VxqjbvbQk9srgyO61mWKswCh1/VV0oAfW1D+c4Rkt7Hh1VlKmQDW8ChgujBBVS4Lqnuwez60oY1hYeFoHWBtJQET68XghSM/nTqyfqpXDc/hfrT9zKWGOFSPx0s2RF4T4EIugspDRIot2NHP8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Qk75Wxh1; 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="Qk75Wxh1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 414431F00898; Wed, 10 Jun 2026 16:52:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781110352; bh=Z8LBu98PZHrCyXJxETKiHVxoJv+6W+cQ+c/mczfZabw=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Qk75Wxh1O7dBeUfBeGymhhitg+bRlBuAOnKGse9MljGqA6hxQmf9hQ7NwR2UUye+u /XjabPrQC5EzRa2mJ2CjWxS5mNcknVIbuzTU4yKKh1EG4Goey74R3nh4h99Bk/+E67 0NLQqmG9rV8aG3t+uh9W0rz7wAt05NhMVIKJIIdApuqohApw+cM6NuVgT54Fxu07Gn Vm+RJ0k/ut17bnJH7P11uLPPtk08rNGEU5jOj8dN2DYEaBAE2qRLv7obYxt4VsNUVH CbSQPwfpTFxM59ZYHxr/aDLfjhuXJwOuHJzUrxv0yngx2PDw80fpMI8gXJjkt79D/l sfDdjJyk47ATA== 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 , Kan Liang , "Claude Opus 4.6" Subject: [PATCH 03/11] perf tools: Use perf_env__get_cpu_topology() in machine__resolve() Date: Wed, 10 Jun 2026 13:51:57 -0300 Message-ID: <20260610165207.2077258-4-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260610165207.2077258-1-acme@kernel.org> References: <20260610165207.2077258-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 machine__resolve() accesses env->cpu[al->cpu].socket_id after checking al->cpu >=3D 0 and env->cpu !=3D NULL, but without validating al->cpu against env->nr_cpus_avail. Since al->cpu comes from the untrusted perf.data sample, a crafted file with a large CPU index causes an out-of-bounds heap read. Use perf_env__get_cpu_topology() which validates both NULL and bounds. Also bounds-check al->cpu before the cast to struct perf_cpu (int16_t): without this, values like 65536 silently truncate to 0, bypassing the accessor's internal check and returning CPU 0's topology. Fixes: 0c4c4debb0adda4c ("perf tools: Add processor socket info to hist_ent= ry and addr_location") Reported-by: sashiko-bot Cc: Kan Liang Cc: Ian Rogers Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers --- tools/perf/util/event.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c index 66f4843bb235df53..ea75816d126a14be 100644 --- a/tools/perf/util/event.c +++ b/tools/perf/util/event.c @@ -14,6 +14,7 @@ #include #include "cpumap.h" #include "dso.h" +#include "env.h" #include "event.h" #include "debug.h" #include "hist.h" @@ -836,8 +837,18 @@ int machine__resolve(struct machine *machine, struct a= ddr_location *al, if (al->cpu >=3D 0) { struct perf_env *env =3D machine->env; =20 - if (env && env->cpu) - al->socket =3D env->cpu[al->cpu].socket_id; + /* + * Bounds-check al->cpu (s32) before casting to struct perf_cpu + * (int16_t): without this, e.g. 65536 truncates to 0 and silently + * returns CPU 0's topology. Can go once perf_cpu.cpu is widened. + */ + if (env && al->cpu < env->nr_cpus_avail) { + struct cpu_topology_map *topo; + + topo =3D perf_env__get_cpu_topology(env, (struct perf_cpu){ al->cpu }); + if (topo) + al->socket =3D topo->socket_id; + } } =20 /* Account for possible out-of-order switch events. */ --=20 2.54.0 From nobody Thu Jun 25 01:53:41 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 15E5433C52F; Wed, 10 Jun 2026 16:52: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=1781110359; cv=none; b=ZH4LDuEj44WeY3W71kQ+F6+Bz3F6aqzEnsoLUvZe14dCZZwwZVFAb+LkTMXNVPnzgQb42OI/3+kWV/P5cRSeG0mww2tXShp/9D6e/v9x6gD+N9lLLDjT09l5kmV3OKW7/ojYcqWWRBXojhvXFNQX0DuMtK5ObEU7ZcfnUZKSQTw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781110359; c=relaxed/simple; bh=14znaSbE/vYKbUSLkAhlt08WXUSmo+UZRC/Wa4oE7j8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=siwUh6bNF80yetC9ItzRk/s+HLrTrysgvltYZ+qvYc6nXftV3gX+0AejXkWziSJkrY06LiPwnw0ZQd98xeNqZJNTU46TDE1mYJbTGadLPBWE8u57SuHJu9WSYz+yYxPxLuP7G4xje9/xBwJ2ZnHwgR4dPzmz/Y/i+uA3q5En6mw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hFbsYPxN; 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="hFbsYPxN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3D001F00893; Wed, 10 Jun 2026 16:52:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781110357; bh=lnwFl+vrAFuz0a1nuMWuGNi60TEb78fCwlXKArHgfiQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=hFbsYPxNZJiQqSlD+v2acin7WYO39m4tOIs0MGXcRIutF8vbg4Lp/lUPIrFw4stfG VkwTNYMHjsIvGj6svn8E4rdjXcv8OOL7dq/3VIFe47FsGeb9YmT4sRJO5Mv940KCc5 RDO60b+J/BCJaK2ZsdSn7R2Fdwbn8N7kU3+ogpziFt3FqkEafey/LpVqgzEEPyu6T3 0+SASanXMOqZa2zTjWZj5T19qYP+rJBWUa7HkyKzO3SuNcM2jT/s0da+HM84r0f8RT cN6gFA4JpyD0BsVkJh0dzoTQgymmfjt5SDtsr6Upf+oXxclEkVyjeyuFm3Ou6RVE09 RUIgIWNTS2Jgg== 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 , Alexey Budankov , Alexey Bayduraev , "Claude Opus 4.6" Subject: [PATCH 04/11] perf tools: NULL bitmap pointers after bitmap_free() Date: Wed, 10 Jun 2026 13:51:58 -0300 Message-ID: <20260610165207.2077258-5-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260610165207.2077258-1-acme@kernel.org> References: <20260610165207.2077258-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 Two call sites free bitmaps without NULLing the pointer, risking double-free if the structure is reused or cleanup is called twice: - mmap__munmap(): map->affinity_mask.bits - record__mmap_cpu_mask_free(): mask->bits Set each pointer to NULL after bitmap_free(). Fixes: 8384a2600c7ddfc8 ("perf record: Adapt affinity to machines with #CPU= s > 1K") Fixes: f466e5ed6c356d1d ("perf record: Extend --threads command line option= ") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Alexey Budankov Cc: Alexey Bayduraev Cc: Arnaldo Carvalho de Melo Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/builtin-record.c | 1 + tools/perf/util/mmap.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c index a33c78f030d91012..e915390556752b9e 100644 --- a/tools/perf/builtin-record.c +++ b/tools/perf/builtin-record.c @@ -3084,6 +3084,7 @@ static int record__mmap_cpu_mask_alloc(struct mmap_cp= u_mask *mask, int nr_bits) static void record__mmap_cpu_mask_free(struct mmap_cpu_mask *mask) { bitmap_free(mask->bits); + mask->bits =3D NULL; mask->nbits =3D 0; } =20 diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c index d64aec6c7c843e81..358e70c4f3edd077 100644 --- a/tools/perf/util/mmap.c +++ b/tools/perf/util/mmap.c @@ -238,6 +238,8 @@ static void perf_mmap__aio_munmap(struct mmap *map __ma= ybe_unused) void mmap__munmap(struct mmap *map) { bitmap_free(map->affinity_mask.bits); + map->affinity_mask.bits =3D NULL; + map->affinity_mask.nbits =3D 0; =20 zstd_fini(&map->zstd_data); =20 --=20 2.54.0 From nobody Thu Jun 25 01:53:41 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 C2E1032AAA0; Wed, 10 Jun 2026 16:52:43 +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=1781110364; cv=none; b=shZGtYiGnGt7+NTPAfCcMswwLts+tB/yUgBhsDVQXR+kk91GTjujgd6UrtLaljnVtXsOSbmb7LRLuZswJcG36Lz3vbVWi41CbDN1k/STGszGa9UJw4ub1VS/VbYZ/fEpcIFSkHDZEOU3wSNHSaZV0cU6ZcPFovFV/dDB6Z3jGBU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781110364; c=relaxed/simple; bh=gbgEmj5FnGqeb+jNcaD67i/sun09ZZMcr9X58zFNznI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=cCHbPygsRALc9dmhY/nSoSX5EcOoOeVUNnYkkLnghqZrxy+WZFsJBA/pNo6no4rhthgO956rj9stBZvSZYxOj4YePEkvHAKRHIAhCWceEhK3zF9w79UrICL1THyv+lu5k8OZTnkWDRK1eQ/+FIgecIF7Y1dlWdNkeUVRGLRLFBU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YKP+Ss7w; 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="YKP+Ss7w" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 682111F00898; Wed, 10 Jun 2026 16:52:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781110363; bh=RuXvQfclts5+/mbpQrY7sM5dcxkV1xcc9yoYhr43l9o=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=YKP+Ss7wZeH2IfHdmT3bDdda+iOsBJyMebsuKHQO7EZlT/5c9FR4jt8alIwwxIACn rPoSsgjxsSgJWxK5q9ivpGk/ccipuaaS2NKuVIjroHAVyhJcDmbyhkCXddNgPykScb Wv0k/5Kk+8bHvsMQ2EGk6LnptTgiRT2Bewnnf9dNXcmfnI+Z+lGgmP5pE28spKlMAa Ok8ANrlDm0JQCDi9O+X71hNOY4ahcTZlvy67t6ETX33Oxt5NsDpkdpfgiq897L4+ob jte+yq2WazLRghX8cFvwKsw1LhjX2gEoqis5OWNJQ/8BCvpSh3BSjM1vHkaNpDCZCB sFrDRU1FUc+wA== 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 , Yang Jihong , "Claude Opus 4.6" Subject: [PATCH 05/11] perf sched: Bounds-check prio before test_bit() in timehist Date: Wed, 10 Jun 2026 13:51:59 -0300 Message-ID: <20260610165207.2077258-6-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260610165207.2077258-1-acme@kernel.org> References: <20260610165207.2077258-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 timehist_skip_sample() reads prio from untrusted tracepoint data via perf_sample__intval(sample, "prev_prio") without bounds validation. A crafted perf.data with prev_prio >=3D MAX_PRIO (140) causes test_bit() to read past the end of the prio_bitmap, which is only MAX_PRIO bits. Add a prio >=3D 0 && prio < MAX_PRIO check before the test_bit() call. This also makes the !=3D -1 sentinel check explicit as >=3D 0. Fixes: 9b3a48bbe20d9692 ("perf sched timehist: Add --prio option") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Yang Jihong 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 1ff01f03d2ad1ad3..ded511d8518803a0 100644 --- a/tools/perf/builtin-sched.c +++ b/tools/perf/builtin-sched.c @@ -2645,7 +2645,9 @@ static bool timehist_skip_sample(struct perf_sched *s= ched, else if (evsel__name_is(sample->evsel, "sched:sched_switch")) prio =3D perf_sample__intval(sample, "prev_prio"); =20 - if (prio !=3D -1 && !test_bit(prio, sched->prio_bitmap)) { + /* prio comes from untrusted tracepoint data =E2=80=94 bounds-check befo= re test_bit */ + if (prio >=3D 0 && + (prio >=3D MAX_PRIO || !test_bit(prio, sched->prio_bitmap))) { rc =3D true; sched->skipped_samples++; } --=20 2.54.0 From nobody Thu Jun 25 01:53:41 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 3B2B931D72E; Wed, 10 Jun 2026 16:52:49 +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=1781110370; cv=none; b=fyEQhjTyRB8//Kuc+xNYd2GIJBnoXwghwblBDu9PcrYw4WU+DAFZsMkyXmQ300Od43I+xg/EgTExMnr1mwU58LR2HL9lfExyN3x0meH1JomdfS3PTUYoqywCMotDcM+0eUfgAq+atYnoj+VIL5DI8ww7pnMRWQgG/De8E6S+KYY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781110370; c=relaxed/simple; bh=ChZ/VzETVjFxU1t8/XJV+KvRhbiU9Z++AiHo3rLz4CY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=QA+FnxK6pjfe6/8ue18RRfhH+Q3ezh35Q6VAPY+w9Cuy+pXeeDUl4G8QApv+KK580mlimo8xJNyVjBh05EDvNQ+49LawjRF4NAhfYV45s2QAGy6DeFwJrpZYoTgG9WYAaLZD8dH2LxbziAQ1kbusBJb35SThmAPDia+gf4hc7Xk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=f/9k/Crs; 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="f/9k/Crs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0EA591F00893; Wed, 10 Jun 2026 16:52:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781110369; bh=GW9heMHecXhASh30FDBJHV61LxuCJ+9Zw4ZSxVAvLJU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=f/9k/Crs/Cs/w01FWV3G168IrZP5ouJDnqMEHGo0bf334oHfoKVLKTMGeSW2UGEc3 Hv6wwI2teHQ15xLB66EP7kqQc8kpSmlBOPGkCgOr7gfP0iiqN+dBayT4BPoxdC9pGD tFcET8obutBk0pTGU27GfAO2EEgi3fNu3g/Fc+T92xiBgnwYpnf8e0HIedIJnLl8V3 S5B5i8BCAEdjGs7glpy22aydf3beaRoBHwiB6SPcVqeQ59JZXPBY1UQ1Fq8wITpat9 pbHz6LoiWzjQTNLR6x+I3njCqo9bvzJCB71Nh2ZqCQkKStR46Kh3OoCwDF0w+F5CYs DBGovz8VaF7Hg== 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 , Davidlohr Bueso , "Claude Opus 4.6" Subject: [PATCH 06/11] perf sched: Fix idle-hist callchain display using wrong rb_first variant Date: Wed, 10 Jun 2026 13:52:00 -0300 Message-ID: <20260610165207.2077258-7-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260610165207.2077258-1-acme@kernel.org> References: <20260610165207.2077258-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 timehist_print_idlehist_callchain() calls rb_first_cached() on sorted_root, but the sort function (callchain_param.sort) populates it via rb_insert_color() on the plain rb_root member =E2=80=94 not the cached variant. This means rb_leftmost is never set, so rb_first_cached() always returns NULL and the entire callchain summary is silently dropped from --idle-hist output. The original code in ba957ebb54893aca ("perf sched timehist: Show callchains for idle stat") was correct =E2=80=94 it used struct rb_root and rb_first(). The bug was introduced when sorted_root was converted to rb_root_cached without converting the sort insertion path to use rb_insert_color_cached(). Use rb_first(&root->rb_root) to match how the tree was populated. Fixes: cb4c13a5137766c3 ("perf sched: Use cached rbtrees") Reported-by: sashiko-bot Cc: Davidlohr Bueso Cc: Namhyung Kim Acked-by: Ian Rogers Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/builtin-sched.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c index ded511d8518803a0..85f11d388392d316 100644 --- a/tools/perf/builtin-sched.c +++ b/tools/perf/builtin-sched.c @@ -3130,7 +3130,8 @@ static size_t timehist_print_idlehist_callchain(struc= t rb_root_cached *root) size_t ret =3D 0; FILE *fp =3D stdout; struct callchain_node *chain; - struct rb_node *rb_node =3D rb_first_cached(root); + /* sort() uses rb_insert_color() on rb_root, not rb_root_cached */ + struct rb_node *rb_node =3D rb_first(&root->rb_root); =20 printf(" %16s %8s %s\n", "Idle time (msec)", "Count", "Callchains"); printf(" %.16s %.8s %.50s\n", graph_dotted_line, graph_dotted_line, --=20 2.54.0 From nobody Thu Jun 25 01:53:41 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 B3E28344D9F; Wed, 10 Jun 2026 16:52:54 +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=1781110375; cv=none; b=JDKvVzM9qDbBlNqb02LvarH4ZkCCrJgHF/jV7jroDUmmxT8ES6fOPvYLX8coQdjWs8QBUsM5hrXc/rStqVSWGoPRcytRyHNzqpFll9nvUFI1aKcwpAygavN0rJzxB5dMljh0cuP+umCISSc8m9a5aUWdBlaaxduoVKsvdGoAnAg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781110375; c=relaxed/simple; bh=KUkXd3UmVYJ5G4qR8v6h3usi2oQZnk0unbjDo4vQ5aE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HvKDX9iMmG6FJ2kMLXVhUF4yDZD9f2zXSLz8z/yzbMTlfrm3NnkzRxKAvnPJT2oeMfYJTNGXN7t4QlQcnCXZ2fR5/57EJRR0XJK8AihfAlFiL2MQQE4s7RuoSPx6SA54YDfIpkeAZNorkkOqMl7M3yYxFjjhNEMO/uJKa74j3BM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KtWXP9e7; 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="KtWXP9e7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C25CB1F00898; Wed, 10 Jun 2026 16:52:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781110374; bh=ONf0Z5SkF9NCm7gcFgIhuCkhUSzRzpwU26c5Vm99WsQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=KtWXP9e74Ahzq/KERIRjywMgfsxEXxdc9ekgHDzfZDpusR/93B3BAqJa0XIC7fzxy p2tup9G/xUCF7Ci/DVQfEu2OUW0AAKU7+BLkoBss6dCNUx+XQJgPQWrkGReal5dXYv e4Qg1I+PGtuqNgo4qPayEnqqUAtiO2UL7arcbqGNAV2/dh7ZuRAgtap2OI5mf8vCp4 5GJQ+dB2CAnd2KKx733G8toB4nouUu7PtpLEByFiG6G+VKeKzMSnPdTHSQkDVa3TO9 KbmAr6eZmAxUyYGfoOLQt7mrpupcdVGN6eG5dtcLHPKmbeyVid9HakehYFLAchjMdu Oic+5lfe+hypg== 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 07/11] perf tools: Add O_CLOEXEC to open() calls in DSO and ELF code Date: Wed, 10 Jun 2026 13:52:01 -0300 Message-ID: <20260610165207.2077258-8-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260610165207.2077258-1-acme@kernel.org> References: <20260610165207.2077258-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 open() calls in dso.c and symbol-elf.c omit O_CLOEXEC, which leaks file descriptors to child processes spawned during symbol resolution (e.g., addr2line, objdump). This can exhaust the fd limit during long profiling sessions or when processing many DSOs. Add O_CLOEXEC to all open() calls in both files (12 call sites). Fixes: cdd059d731eeb466 ("perf tools: Move dso_* related functions into dso= object") Fixes: e5a1845fc0aeca85 ("perf symbols: Split out util/symbol-elf.c") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Jiri Olsa Cc: Namhyung Kim Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/dso.c | 4 ++-- tools/perf/util/symbol-elf.c | 20 ++++++++++---------- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c index 7dced896c64eafd7..fb2e78fe2aa8eb94 100644 --- a/tools/perf/util/dso.c +++ b/tools/perf/util/dso.c @@ -344,7 +344,7 @@ int filename__decompress(const char *name, char *pathna= me, * descriptor to the uncompressed file. */ if (!compressions[comp].is_compressed(name)) - return open(name, O_RDONLY); + return open(name, O_RDONLY | O_CLOEXEC); =20 fd =3D mkstemp(tmpbuf); if (fd < 0) { @@ -1911,7 +1911,7 @@ static const u8 *__dso__read_symbol(struct dso *dso, = const char *symfs_filename, int saved_errno; =20 nsinfo__mountns_enter(dso__nsinfo(dso), &nsc); - fd =3D open(symfs_filename, O_RDONLY); + fd =3D open(symfs_filename, O_RDONLY | O_CLOEXEC); saved_errno =3D errno; nsinfo__mountns_exit(&nsc); if (fd < 0) { diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c index 186e6d92ac3d7742..c2bdfd0003df2abe 100644 --- a/tools/perf/util/symbol-elf.c +++ b/tools/perf/util/symbol-elf.c @@ -217,7 +217,7 @@ bool filename__has_section(const char *filename, const = char *sec) GElf_Shdr shdr; bool found =3D false; =20 - fd =3D open(filename, O_RDONLY); + fd =3D open(filename, O_RDONLY | O_CLOEXEC); if (fd < 0) return false; =20 @@ -872,7 +872,7 @@ static int read_build_id(const char *filename, struct b= uild_id *bid) if (size < BUILD_ID_SIZE) goto out; =20 - fd =3D open(filename, O_RDONLY); + fd =3D open(filename, O_RDONLY | O_CLOEXEC); if (fd < 0) goto out; =20 @@ -935,7 +935,7 @@ int sysfs__read_build_id(const char *filename, struct b= uild_id *bid) size_t size =3D sizeof(bid->data); int fd, err =3D -1; =20 - fd =3D open(filename, O_RDONLY); + fd =3D open(filename, O_RDONLY | O_CLOEXEC); if (fd < 0) goto out; =20 @@ -995,7 +995,7 @@ int filename__read_debuglink(const char *filename, char= *debuglink, if (err >=3D 0) goto out; =20 - fd =3D open(filename, O_RDONLY); + fd =3D open(filename, O_RDONLY | O_CLOEXEC); if (fd < 0) goto out; =20 @@ -1153,7 +1153,7 @@ int symsrc__init(struct symsrc *ss, struct dso *dso, = const char *name, =20 type =3D dso__symtab_type(dso); } else { - fd =3D open(name, O_RDONLY); + fd =3D open(name, O_RDONLY | O_CLOEXEC); if (fd < 0) { *dso__load_errno(dso) =3D errno; return -1; @@ -1952,7 +1952,7 @@ static int kcore__open(struct kcore *kcore, const cha= r *filename) { GElf_Ehdr *ehdr; =20 - kcore->fd =3D open(filename, O_RDONLY); + kcore->fd =3D open(filename, O_RDONLY | O_CLOEXEC); if (kcore->fd =3D=3D -1) return -1; =20 @@ -1985,7 +1985,7 @@ static int kcore__init(struct kcore *kcore, char *fil= ename, int elfclass, if (temp) kcore->fd =3D mkstemp(filename); else - kcore->fd =3D open(filename, O_WRONLY | O_CREAT | O_EXCL, 0400); + kcore->fd =3D open(filename, O_WRONLY | O_CREAT | O_EXCL | O_CLOEXEC, 04= 00); if (kcore->fd =3D=3D -1) return -1; =20 @@ -2461,11 +2461,11 @@ static int kcore_copy__compare_files(const char *fr= om_filename, { int from, to, err =3D -1; =20 - from =3D open(from_filename, O_RDONLY); + from =3D open(from_filename, O_RDONLY | O_CLOEXEC); if (from < 0) return -1; =20 - to =3D open(to_filename, O_RDONLY); + to =3D open(to_filename, O_RDONLY | O_CLOEXEC); if (to < 0) goto out_close_from; =20 @@ -2883,7 +2883,7 @@ int get_sdt_note_list(struct list_head *head, const c= har *target) Elf *elf; int fd, ret; =20 - fd =3D open(target, O_RDONLY); + fd =3D open(target, O_RDONLY | O_CLOEXEC); if (fd < 0) return -EBADF; =20 --=20 2.54.0 From nobody Thu Jun 25 01:53:41 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 3FA7C3537F8; Wed, 10 Jun 2026 16:52:59 +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=1781110381; cv=none; b=iydBXe4Y0z2F1i72xEhPvwCVUrkLkzTNyc+3EqRAHzE9d3gQmDaaDBPTNglJPiZpGys8CBk9F954m9JPy1cyUqNGIkPIXhf5ilbjHMQxH3uaOpjwaOGb/o4sDuKZBCQjPS50zpmmkc1o+o5CPvo0AkG3l88rLmcGtLdRSMa2SGM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781110381; c=relaxed/simple; bh=7n6+PW6fm4CnN5i0Kkq2sFG6oHBydJcqFEad0lVdCCY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=X0zF++tHdBmjA8lA8UaPamrMOiI8AyxcvdjnM2/44NvIg9qzOa+w77uAmn0yb47a8MDTT2g1doPgA7fX7tZ9uWOV1kd2SHqv90wXfbGHjwA8YQbM1UoHLQsolqU6gtDBgAKOLT6TDHS8IJbGw7KGIqwZtkv8QovIoLaZ58yOwWQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JSbiAm/z; 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="JSbiAm/z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1CCA51F00893; Wed, 10 Jun 2026 16:52:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781110379; bh=9Sna/5EcUpDAGkIvriG0r7m33IdzGdkBg8h/2wBoRA4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=JSbiAm/zpozYjFF+z1B7Se+I1nlMQ1hjQM7gJFPRc1ZjCyhAd4kj5P1i9qdhcDv39 gzgMRlGMjsfrz3Vrb1yjJzyvNQuguEjgGq+dEWt1lHtp8h8nv9YMSH170TuJV5Y2y1 xL0TVbth/HcAu61jp3sEtclOCTG0P6KXTd5HXGJqDMlKhn/xvQoiYVLkAkUHj35sMk QJj1ixsu5oKFU2XJBGGc4gxhu77AKn3Q6StgIVMIT1pfEtwoipZJXseSpLT5LOPtcS QpZheylskyuAcO7OU4cNMls/xjgGULAUeWj49X7nW8MEKlutdiRqcE7UBksVzzx1zJ OQcaaMbWkNXzw== 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 , Song Liu , "Claude Opus 4.6" Subject: [PATCH 08/11] perf bpf: Use scnprintf() in snprintf_hex() and synthesize_bpf_prog_name() Date: Wed, 10 Jun 2026 13:52:02 -0300 Message-ID: <20260610165207.2077258-9-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260610165207.2077258-1-acme@kernel.org> References: <20260610165207.2077258-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 Both functions accumulate formatted output via ret +=3D snprintf(buf + ret, size - ret, ...). If the buffer is too small and snprintf() returns more than the remaining space, ret exceeds size and the next 'size - ret' underflows, causing snprintf() to write past the buffer end. Switch to scnprintf() which returns the actual number of bytes written, making the accumulation safe. Fixes: 7b612e291a5affb1 ("perf tools: Synthesize PERF_RECORD_* for loaded B= PF programs") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Song Liu Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/bpf-event.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/tools/perf/util/bpf-event.c b/tools/perf/util/bpf-event.c index a27945c279efb779..2c09842469f1f28c 100644 --- a/tools/perf/util/bpf-event.c +++ b/tools/perf/util/bpf-event.c @@ -36,7 +36,7 @@ static int snprintf_hex(char *buf, size_t size, unsigned = char *data, size_t len) size_t i; =20 for (i =3D 0; i < len; i++) - ret +=3D snprintf(buf + ret, size - ret, "%02x", data[i]); + ret +=3D scnprintf(buf + ret, size - ret, "%02x", data[i]); return ret; } =20 @@ -140,7 +140,7 @@ static int synthesize_bpf_prog_name(char *buf, int size, const struct btf_type *t; int name_len; =20 - name_len =3D snprintf(buf, size, "bpf_prog_"); + name_len =3D scnprintf(buf, size, "bpf_prog_"); name_len +=3D snprintf_hex(buf + name_len, size - name_len, prog_tags[sub_id], BPF_TAG_SIZE); if (btf) { @@ -153,9 +153,10 @@ static int synthesize_bpf_prog_name(char *buf, int siz= e, short_name =3D info->name; } else short_name =3D "F"; - if (short_name) - name_len +=3D snprintf(buf + name_len, size - name_len, - "_%s", short_name); + if (short_name) { + name_len +=3D scnprintf(buf + name_len, size - name_len, + "_%s", short_name); + } return name_len; } =20 --=20 2.54.0 From nobody Thu Jun 25 01:53:41 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 018983537F8; Wed, 10 Jun 2026 16:53:05 +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=1781110386; cv=none; b=ibQr2ewjtXCKk9vDL3Rrj653L2nmrHEE13pSP2yTtBnX2NDaZKDdS6xIB40GSWm+IDolX0xei3WjkGdjXWGNgylZMi+I1U9Lord7ERCOjNQ20lnS6qjEjDM/w05uzMxDC5lWnyARDPlCVzGBCAgkkim0TeyeagFN/LDV8A+YTzM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781110386; c=relaxed/simple; bh=Ao0pr5PgFb/7acac5QMQ2VYwhC/VuHpVSMrd3T6jF4g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Me3pEmj6LnFP49sIcFk3A+tZhI4SNQlnbA8knJInw2CXaei86fBzykGVSJLopyMe2NLJ5Yss+TcUxPVgAmx1TK9RR9WJ9TYsum1N71XzaA2bNp2beIO903fv9C8So7pm/931R3h2LUJjgCo9i3wSUagGnRNoCyeuAb9VdPrWSUE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=e/fXoqaA; 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="e/fXoqaA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C0B21F00898; Wed, 10 Jun 2026 16:52:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781110384; bh=jSu3ugF2bQlEjkN56aaNfMrbvtlHHc0IVuql6K9Qrck=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=e/fXoqaANWckjmtRTgnNCLPbikvbpG/r0npIR5k66+BukBFQzLwddlZuLi4cD7mkE NvVG3qtQ0v3+ftmKRh8haGwsxFOjcpCqDxJpRp5FHfUpSA3xO/lwcXzpHosapdrM0f cv54S1i+kG1UraNhtLtxmD70mDILAs8FtMMqz7RUji3OvDXdJwYkfDOE5qv4iXHMFO tGutoqWZtmDy+mkTtqebIP7BTBIhF/tuMBlEaYIzxOo4sfWsTRrDQHbQemy0DLv9Wp xQJHOwPdIjGsyNJKqo5x/cTPK9ncYBRtrU7oH+lhEt35QAzXFgYUCnZ44Yd1v7twu0 F58mPLy0/j0iw== 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 09/11] perf hists: Fix snprintf() in hists__scnprintf_title() UID filter path Date: Wed, 10 Jun 2026 13:52:03 -0300 Message-ID: <20260610165207.2077258-10-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260610165207.2077258-1-acme@kernel.org> References: <20260610165207.2077258-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 hists__scnprintf_title() accumulates formatted output into a buffer using scnprintf() for all filter clauses except the UID filter, which uses snprintf(). If the buffer fills up and snprintf() returns more than the remaining space, printed exceeds size and the next 'size - printed' underflows, causing later scnprintf() calls to write past the buffer. Switch the UID filter clause to scnprintf() to match the rest of the function. Fixes: 25c312dbf88ca402 ("perf hists: Move hists__scnprintf_title() away fr= om the TUI code") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Arnaldo Carvalho de Melo Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/hist.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c index 811d68fa6770c5b7..df978c996b6c2262 100644 --- a/tools/perf/util/hist.c +++ b/tools/perf/util/hist.c @@ -2963,9 +2963,10 @@ int __hists__scnprintf_title(struct hists *hists, ch= ar *bf, size_t size, bool sh ev_name, sample_freq_str, enable_ref ? ref : " ", nr_events); =20 =20 - if (hists->uid_filter_str) - printed +=3D snprintf(bf + printed, size - printed, - ", UID: %s", hists->uid_filter_str); + if (hists->uid_filter_str) { + printed +=3D scnprintf(bf + printed, size - printed, + ", UID: %s", hists->uid_filter_str); + } if (thread) { if (hists__has(hists, thread)) { printed +=3D scnprintf(bf + printed, size - printed, --=20 2.54.0 From nobody Thu Jun 25 01:53:41 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 AE2CD346784; Wed, 10 Jun 2026 16:53:10 +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=1781110391; cv=none; b=H4GCkCtYOCJgYNLRbeXyekKQNp2phb6+E7l2uHI+qdrYDvmBVzRZtnLktbvSV5JGm+B5/NKIqOwY+PvT8ujDuQ0YS/LN2JrLmA9AaQQjiOegYdtvogYMj9ynMb+CIYhs4Dn/K6YE0ACIb1iaTraSqvzLM+3W4w7RfvC1+pOh2xc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781110391; c=relaxed/simple; bh=4SguA8Ny2p++3uPgBM0X7q02tqLWqv9iRtYhwCJP6QA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=I7vNH2BldyKb/EWHl4nwCVfk0qDmkxHWF9N7wqS9ZgAobx1FdTVuCrXWDj/SFZ58LbBW2xXC1CjI6t8von5k2NHfI1g1GyQ+wZNJSRRBpzee9ogUHZOYUvtZuajZAWK+aC9pKoj1DLKZG7ZWKUklHzP/KUQ1FbectP+eMS3KRJs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nt87A4b7; 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="nt87A4b7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89D8A1F00893; Wed, 10 Jun 2026 16:53:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781110390; bh=ShhRyTxBectfJ6K9wTi0v17IdF7h8yiTR8h/Ofl/l0A=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=nt87A4b77uR9Gezz7ObCqAhGOkJHd8CM/y0dSS1eD9vxOc+4F4upumZrQUAs59f3t lG2QSgas6Lqhwpj9qWh1VfAUAa/Lh5J4RcPGXeRhUh3u5q+6O4xY5Oc+VzACUai9sC JP6snDoC6bXV0QISuCzAOooQiDncU0qet/twSIuXTGOMFwwTkYzeyGww9blAC5QaXC 3cx4ljmkuOht1U6xQhC8kT7dBcBjYgrInEQnxx6cu3J2qhZ1XT/L20Jd464cE9sbZ/ WOhBvEG+GX66c/xB5X5jG11z5qz4TOlT8cyhOqIzrWyYY2KrVwT9W5RfdhGqR/2c5/ hNnRhewn9FIgw== 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 10/11] perf tools: Use scnprintf() in build_id__snprintf() and hwmon read_events() Date: Wed, 10 Jun 2026 13:52:04 -0300 Message-ID: <20260610165207.2077258-11-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260610165207.2077258-1-acme@kernel.org> References: <20260610165207.2077258-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 build_id__snprintf() and hwmon_pmu__read_events() accumulate formatted output via snprintf(), which returns the would-have-been-written count on truncation. In build_id__snprintf(), this inflates the return value beyond the buffer size. In hwmon_pmu__read_events(), len overshoots out_buf_len and the next 'out_buf_len - len' underflows. Switch both to scnprintf() which returns actual bytes written. In build_id__snprintf(), also tighten the loop guard from 'offs < bf_size' to 'offs + 1 < bf_size': since scnprintf() returns at most size-1, offs never reaches bf_size, and the original condition would spin doing zero-byte writes once the buffer fills. Fixes: fccaaf6fbbc59910 ("perf build-id: Change sprintf functions to snprin= tf") Fixes: 53cc0b351ec99278 ("perf hwmon_pmu: Add a tool PMU exposing events fr= om hwmon in sysfs") Reported-by: sashiko-bot Cc: Ian Rogers Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/build-id.c | 7 +++++-- tools/perf/util/hwmon_pmu.c | 12 ++++++------ 2 files changed, 11 insertions(+), 8 deletions(-) diff --git a/tools/perf/util/build-id.c b/tools/perf/util/build-id.c index 8c0a9ae932aa5798..eb95ab90f9741d5f 100644 --- a/tools/perf/util/build-id.c +++ b/tools/perf/util/build-id.c @@ -93,8 +93,11 @@ int build_id__snprintf(const struct build_id *build_id, = char *bf, size_t bf_size return 0; } =20 - for (size_t i =3D 0; i < build_id->size && offs < bf_size; ++i) - offs +=3D snprintf(bf + offs, bf_size - offs, "%02x", build_id->data[i]); + if (bf_size > 0) + bf[0] =3D '\0'; + + for (size_t i =3D 0; i < build_id->size && offs + 1 < bf_size; ++i) + offs +=3D scnprintf(bf + offs, bf_size - offs, "%02x", build_id->data[i]= ); =20 return offs; } diff --git a/tools/perf/util/hwmon_pmu.c b/tools/perf/util/hwmon_pmu.c index fb3ffa8d32ad2a93..dbf6a71af47f9a42 100644 --- a/tools/perf/util/hwmon_pmu.c +++ b/tools/perf/util/hwmon_pmu.c @@ -442,12 +442,12 @@ static size_t hwmon_pmu__describe_items(struct hwmon_= pmu *hwm, char *out_buf, si =20 buf[read_len] =3D '\0'; val =3D strtoll(buf, /*endptr=3D*/NULL, 10); - len +=3D snprintf(out_buf + len, out_buf_len - len, "%s%s%s=3D%g%s", - len =3D=3D 0 ? " " : ", ", - hwmon_item_strs[bit], - is_alarm ? "_alarm" : "", - (double)val / 1000.0, - hwmon_units[key.type]); + len +=3D scnprintf(out_buf + len, out_buf_len - len, "%s%s%s=3D%g%s", + len =3D=3D 0 ? " " : ", ", + hwmon_item_strs[bit], + is_alarm ? "_alarm" : "", + (double)val / 1000.0, + hwmon_units[key.type]); } close(fd); } --=20 2.54.0 From nobody Thu Jun 25 01:53:41 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 55CDE337BA4; Wed, 10 Jun 2026 16:53:15 +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=1781110396; cv=none; b=iPJoMxzNtrP/5UJD9ZRKeKHpa0Z9fsulziuKZ91opJAl7nlyadOQVZhgUQhq2Ee8UmJ3x6bB2hj7q4uZXSCiCKHUqFvrKbI2E6kUAgrvLslAqbojk8JPWzsz+HMpSMHgBrhCTrFP8f7xMm1Mp64cqGlFjZ9P7Aw2HhmtVsZixys= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781110396; c=relaxed/simple; bh=whP9jx6KDB4/4o+dk2mUw7td7rlHM3I1owTU6AcY++Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=L6VMx4UwSlSothNE1saDgjUBCJ6LyKLN+mNzx6MgJ+ks5skNMC3EWfdp6+x5GXVweLXnjeoxEeKzTdD7XOjTUlDJmuH2N12LCRym9BElGPcCmluhoPCpHYW1c18014ThpiCaBwKL3uHGW+pDyOUqke0yBCCeRdN717b9Jv8xndQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=f73m++uK; 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="f73m++uK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D96A21F00898; Wed, 10 Jun 2026 16:53:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781110395; bh=TyfKr8lVqchVJszhm+AWCn41Ltfy4bgQtnnQFKxtpF0=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=f73m++uKocx5TMIN7ov/u0Dc5HlbuizzBBvfSRnO6gDutnZsiL1UZn1hAP4yGFUeM MISvHlrcNrmWUK46gaIKbLDtiYW6yINtuC0th9UIgsWEfvwASoZSyG52AQUvFAJLlD 615oKAAFkeWI89l3DVMARh0j9s9cJi8CFcFgyJ4tZIPpSAsyl+KfUQuQ0w2BLZbI6L EbxNezXrXMyH9RKwPWtQFhaMnm2qVmAEE4Or5zGPuChiRHiMtojVdVDTi7qer1yIE1 6gUz7UmeGnMux8HYxNkL4TJ9R0yuLiM4exIZqD4437fV2vwUBqcAtsRFmfWn+5Fps9 6Q4RGFJpWvH3Q== 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 , "Claude Opus 4.6" Subject: [PATCH 11/11] libperf: Document code simplification case for widening struct perf_cpu Date: Wed, 10 Jun 2026 13:52:05 -0300 Message-ID: <20260610165207.2077258-12-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260610165207.2077258-1-acme@kernel.org> References: <20260610165207.2077258-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 Add a bullet point to the libperf ABI TODO explaining the code simplification benefit of widening struct perf_cpu.cpu from int16_t to int: the narrow type forces defensive truncation checks at every boundary where wider CPU indices are narrowed, and values > 32767 silently wrap to negative numbers (two's complement), bypassing bounds validation without them. Cc: Ian Rogers Cc: Namhyung Kim Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo --- tools/lib/perf/TODO | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/tools/lib/perf/TODO b/tools/lib/perf/TODO index 486dd95dc57208a8..e179728697d8c7c0 100644 --- a/tools/lib/perf/TODO +++ b/tools/lib/perf/TODO @@ -11,6 +11,14 @@ together. (x86_64 max is 8192, arm64 is 4096), but NR_CPUS limits keep growing. perf clamps to INT16_MAX in set_max_cpu_num() as a safety net. + - Code simplification: the int16_t forces defensive truncation + checks at every boundary where a wider CPU index (int from + sample->cpu, al->cpu, etc.) is narrowed into struct perf_cpu. + Without these checks, values > 32767 silently wrap to negative + numbers (two's complement), bypassing bounds validation. + Widening to int eliminates this entire class of silent + truncation bugs and removes the need for the INT16_MAX clamp + in set_max_cpu_num(). - Scope: struct perf_cpu is embedded everywhere =E2=80=94 perf_cpu_map_= _cpu(), perf_cpu_map__min(), perf_cpu_map__max(), perf_cpu_map__has(), the for_each_cpu macros, and all internal callers. The perf_cpu_map --=20 2.54.0