From nobody Sat Sep 26 04:29:48 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 BFC523A1E92; Fri, 4 Sep 2026 14:41:12 +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=1788532874; cv=none; b=kWbVYNKeRNTljsuYgbdag02goxZ5o/3oUcxM0UQPsBxXHH1HZNhuao0QyE87NmHm7ktgFA0wl3x5cqbxnCkjT6Ma/YyB44KiXgPnbhpIvihG9vnJfX+GZN5CvJ+w4JDb1bb3Lu8IT+k2Tyl3GbgztYJe5tnAbTQ2ac1CYUxGr1g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788532874; c=relaxed/simple; bh=WU7m4HlKW3kdHtsYh/Q0n1wYe988EY4t+zrtpzwPc+Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MLeDRmUJ30hLd78XTOfYhFcx7BdViS6ZBN834qs6BOFKR5Dj4QQ8rzPQV7p2PIkFdOFS8aF0ETIaWghrSogo3N8qMDIVQMzWV6oo1uDHCpbSVSByp4o3M4QQTkQkpxC0WcQMRd4KNKHS93MocizikTj4OFtAQSCDwGOTMbXV4JY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=diHLz92k; 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="diHLz92k" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1469B1F00A3E; Fri, 4 Sep 2026 14:41:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788532872; bh=EHKFKHJ3yJDXjG8mIdYl0n+9u/+CfaZfUFzjPOjHdgs=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=diHLz92kXqz+2DaoevwFsmDvDc772J9Ml0bteABvvowMRdATaPKg3+PmWJEGDJyvG fjjkRqdL5uwADIoAQz+o2VokLNf2C5Vw0lQxO75z6+Z6ucFJNB22jEtkqmfEF4SR+C Ss7fArftF9qnaenPjbQc1DXh6cJ1jJHrngsF5dSx7ncIQBnyguDRJRvK6B1CSV0q83 OvwTvq3QNqAZE/qaTueJZRONefs7mc5bWdgPYicg03a2WRJsj0fQhLPLLXq7aBiJ2y yvlAb7AiaIuXZiBtUdB3upTNIVsO9Ru3VzcYqsx0qfTVpwoKjulbWy2EmyIDZXmCKY zUFIo4MrWvIPw== 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 , Stephane Eranian Subject: [PATCH 1/5] perf jitdump: Byte-swap debug entries via unaligned-safe accessors Date: Fri, 4 Sep 2026 11:40:53 -0300 Message-ID: <20260904144058.3341-2-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260904144058.3341-1-acme@kernel.org> References: <20260904144058.3341-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 debug_entry records are packed with a variable-length name[] field, so entries after the first may start at addresses that are not naturally aligned for their u64 addr and int lineno/discrim fields. On strict alignment architectures the byte-swap loop in jit_get_next_entry() performed misaligned 64-bit loads and stores through struct member access, which is undefined behavior. Use get_unaligned()/put_unaligned() for the byte-swap of each field. Reported-by: sashiko-bot Cc: Stephane Eranian Assisted-by: LLM Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/jitdump.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/tools/perf/util/jitdump.c b/tools/perf/util/jitdump.c index d25a9fe9b020ce87..e0d5cc9a828189a2 100644 --- a/tools/perf/util/jitdump.c +++ b/tools/perf/util/jitdump.c @@ -14,6 +14,8 @@ #include #include #include +#include +#include =20 #include "event.h" #include "debug.h" @@ -343,9 +345,14 @@ jit_get_next_entry(struct jit_buf_desc *jd) /* name must be NUL-terminated within the record */ if (!memchr(ent->name, '\0', (char *)end - ent->name)) break; - ent->addr =3D bswap_64(ent->addr); - ent->lineno =3D bswap_32(ent->lineno); - ent->discrim =3D bswap_32(ent->discrim); + /* + * debug entries are packed with a variable-length + * name[], so entries after the first may be + * unaligned: byte-swap via unaligned-safe accessors. + */ + put_unaligned(bswap_64(get_unaligned(&ent->addr)), &ent->addr); + put_unaligned(bswap_32(get_unaligned(&ent->lineno)), &ent->lineno); + put_unaligned(bswap_32(get_unaligned(&ent->discrim)), &ent->discrim); ent =3D debug_entry_next(ent); } /* clamp so downstream consumers don't overrun */ --=20 2.55.0 From nobody Sat Sep 26 04:29:48 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 D861D4746A5; Fri, 4 Sep 2026 14:41:16 +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=1788532878; cv=none; b=u2OSfJAI/skqkmg/DF0SAKsF6XFGDfWuWUTq9IfXMrZPVxaPyz2/qzaIV16oEzDNIPkG3JeN9ErlOzKrtkZR0KE4H+WvAyDqPLecYdbNhD5W6Sipn14+oWk5e3Er/hrwMnnBhnyspiNBKZYP3vr+vvY8IfXkiGJcD0Op7OytmLg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788532878; c=relaxed/simple; bh=KWNQw2IQ/2CL24U6l4KTkjBiISA1RV3mmnp2TkI7qTc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AC/hMr6hkXLHip7CSnlETHWpcYbvh/fAgoi6ILHMPq0csbnAgXW+8TybmIvRpArO5Z/RU8ztUIPw7opgJI+SCIgdcFNV/bwWX7CEMF6uieqKKdgTQSMl9iiu1tXMYOwweMqlCPESpQ4HR+zlMkblWorZu161k6scdtqUMH/irak= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=X6N0JG4y; 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="X6N0JG4y" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3690A1F00A3D; Fri, 4 Sep 2026 14:41:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788532876; bh=btJOcrj4wsYapHm+mAfsBpBmkL8dxGs1yHtXcd4dJzQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=X6N0JG4ymWkL/NEGRmCMUIvOYHK/aNrLD5FsYTOJ1mowgWV9fHUd4t90u/fxsp7/6 zN1BXutXbofNCB0I0IKKfOUTCrv4V9nZZGZKN3ZYe3t4/EQiBL85umOdrP/TMyy3PL MLCsNoZ8LfbFRnGBSArY7QHwhrzdhduUZUdJXir7mBW0LnX4BvTNNAJcidnVjkxnph AuZarGts5ZV7q/gkmqyVTYw3+B1ydCdZiTsxoSlRkTMD8ruc5RZXCwHemVRLwIzaiA A1JRFNysuuoC80CnFN+jyhi6hm6pG6qjIY/hQcaPrKKxnCBn6bQEPjq9qTA8S12jkL hu0wQDmv6i6Dg== 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 , Stephane Eranian Subject: [PATCH 2/5] perf genelf: Use unaligned-safe accessors for debug entries Date: Fri, 4 Sep 2026 11:40:54 -0300 Message-ID: <20260904144058.3341-3-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260904144058.3341-1-acme@kernel.org> References: <20260904144058.3341-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 debug_entry records are packed with a variable-length name[] field, so entries after the first may start at addresses that are not naturally aligned. jit_process_debug_info(), get_special_opcode() and emit_lineno_info() read and write the u64 addr and int lineno fields through struct member access, which is undefined behavior on strict-alignment architectures. Use get_unaligned()/put_unaligned() to read and update each field, matching the layout the jitdump writers (LLVM, JVM agents) emit, which packs entries without padding. struct debug_entry.lineno is signed and emit_advance_lineno() takes a long line delta that relies on sign extension, so the field is read into an int: reading it into an unsigned int would turn a backward line jump into a huge forward one and corrupt the line number program. Reported-by: sashiko-bot Cc: Stephane Eranian Assisted-by: LLM Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/genelf_debug.c | 28 +++++++++++++++++----------- 1 file changed, 17 insertions(+), 11 deletions(-) diff --git a/tools/perf/util/genelf_debug.c b/tools/perf/util/genelf_debug.c index 8588b3e35e008396..7d9ef43aa6ac4ab6 100644 --- a/tools/perf/util/genelf_debug.c +++ b/tools/perf/util/genelf_debug.c @@ -12,6 +12,8 @@ */ #include #include +#include +#include #include #include #include @@ -303,11 +305,13 @@ static ubyte get_special_opcode(struct debug_entry *e= nt, { unsigned int temp; unsigned long delta_addr; + int lineno =3D get_unaligned(&ent->lineno); + uint64_t addr =3D get_unaligned(&ent->addr); =20 /* * delta from line_base */ - temp =3D (ent->lineno - last_line) - default_debug_line_header.line_base; + temp =3D (lineno - last_line) - default_debug_line_header.line_base; =20 if (temp >=3D default_debug_line_header.line_range) return 0; @@ -315,7 +319,7 @@ static ubyte get_special_opcode(struct debug_entry *ent, /* * delta of addresses */ - delta_addr =3D (ent->addr - last_vma) / default_debug_line_header.minimum= _instruction_length; + delta_addr =3D (addr - last_vma) / default_debug_line_header.minimum_inst= ruction_length; =20 /* This is not sufficient to ensure opcode will be in [0-256] but * sufficient to ensure when summing with the delta lineno we will @@ -362,6 +366,8 @@ static void emit_lineno_info(struct buffer_ext *be, for (i =3D 0; i < nr_entry; i++, ent =3D debug_entry_next(ent)) { int need_copy =3D 0; ubyte special_opcode; + int lineno =3D get_unaligned(&ent->lineno); + uint64_t addr =3D get_unaligned(&ent->addr); =20 /* * check if filename changed, if so add it @@ -376,24 +382,24 @@ static void emit_lineno_info(struct buffer_ext *be, =20 special_opcode =3D get_special_opcode(ent, last_line, last_vma); if (special_opcode !=3D 0) { - last_line =3D ent->lineno; - last_vma =3D ent->addr; + last_line =3D lineno; + last_vma =3D addr; emit_opcode(be, special_opcode); } else { /* * lines differ, emit line delta */ - if (last_line !=3D ent->lineno) { - emit_advance_lineno(be, ent->lineno - last_line); - last_line =3D ent->lineno; + if (last_line !=3D lineno) { + emit_advance_lineno(be, lineno - last_line); + last_line =3D lineno; need_copy =3D 1; } /* * addresses differ, emit address delta */ - if (last_vma !=3D ent->addr) { - emit_advance_pc(be, ent->addr - last_vma); - last_vma =3D ent->addr; + if (last_vma !=3D addr) { + emit_advance_pc(be, addr - last_vma); + last_vma =3D addr; need_copy =3D 1; } /* @@ -480,7 +486,7 @@ jit_process_debug_info(uint64_t code_addr, int i; =20 for (i =3D 0; i < nr_debug_entries; i++) { - ent->addr =3D ent->addr - code_addr; + put_unaligned(get_unaligned(&ent->addr) - code_addr, &ent->addr); ent =3D debug_entry_next(ent); } add_compilation_unit(di, buffer_ext_size(dl)); --=20 2.55.0 From nobody Sat Sep 26 04:29:48 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 5A73F3EE1EE; Fri, 4 Sep 2026 14:41: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=1788532882; cv=none; b=qIixS0NP3R1camarJeMaBW18LU+odk/1Gt83nFXErwmLmAchICA4CusLViUw2vcgSVw9ppEbxRVBTdL8zAMqmlTLimA4kPULXvvWArLsDpuvIMbHVwUg6WWDZuj8Y1lXSdKA9GYJ07xyUjQQk9Z9Gkv3N4yq5UPKGo2ZnXM/pB4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788532882; c=relaxed/simple; bh=e38JMJdiGHRdfA64u0w6Tx1jh3SRtvwMfz7aiaqj09M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cQoexpN2auCNUyO3Ywh+hRVcytztG12jZ40tt2XGchSb2Z+7h/Dnjk6n/jCd/Kc6hINt9WeXiwxtWcAv8aDJrBEhTgineJ5f9yAohoxWPxa5MyP/i7x1lx1HP3DLZWZKq2uZf5dr6R1/7LiRw7yPdPpjJbS+OpEvsdK2q+pm5AQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cUvd5eNY; 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="cUvd5eNY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4EF621F00A3E; Fri, 4 Sep 2026 14:41:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788532880; bh=zynrnR2EAq/cFIWBv+qsDcjBh1/+RXYsldS58qsToHc=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=cUvd5eNYQ54v0QEIlMEw22g8NGNBTCdBjYjqD8ycmaUDP+BY//oWsQgjQmhhZbaIg cYZ7OHAKqg2bPxrplgxy0ikDg5vjeQeu//OvQW+EVapcwMgI0JYLOjLFGrcTCzm7x0 zTiyGTGxQGg7Yrlmv4QTpZyK7srKwG+9NsSGXfBDkc/XCZhAJsc1qJyxZ+9WN68TR+ qW9pOPL77O602OnSfBSjF94nWk4giyC1qqhtO5vmx5MBMGEvyUBhYPy7AMBTK1Fzpf F2pOoCC2vgzJYTixxIdo3TvT6+qRl9Jz4EWjpAE/K/neFs/RBh1hDk7r+0WW7Dg88g 4ngMXUtCVxr9Q== 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 , Stephane Eranian Subject: [PATCH 3/5] perf jitdump: Free unwinding data even when eh_frame_hdr_size is zero Date: Fri, 4 Sep 2026 11:40:55 -0300 Message-ID: <20260904144058.3341-4-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260904144058.3341-1-acme@kernel.org> References: <20260904144058.3341-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 jit_repipe_code_load() only cleared the unwinding state when both unwinding_data and eh_frame_hdr_size were set. When a record carries unwinding data but eh_frame_hdr_size is 0, the cleanup condition fails and the unwinding state persists in jd, being applied to all subsequent JIT_CODE_LOAD and JIT_CODE_MOVE records, duplicating unwinding sections in the generated ELF files and inflating their event->mmap2.len. The record is validated upstream so eh_frame_hdr_size <=3D unwinding_size always holds. Free the unwinding data based on the data pointer alone. Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Stephane Eranian Assisted-by: LLM Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/jitdump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/jitdump.c b/tools/perf/util/jitdump.c index e0d5cc9a828189a2..efb40d93e33ae664 100644 --- a/tools/perf/util/jitdump.c +++ b/tools/perf/util/jitdump.c @@ -530,7 +530,7 @@ static int jit_repipe_code_load(struct jit_buf_desc *jd= , union jr_entry *jr) jd->nr_debug_entries =3D 0; } =20 - if (jd->unwinding_data && jd->eh_frame_hdr_size) { + if (jd->unwinding_data) { zfree(&jd->unwinding_data); jd->eh_frame_hdr_size =3D 0; jd->unwinding_mapped_size =3D 0; --=20 2.55.0 From nobody Sat Sep 26 04:29:48 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 29C4A4AC15B; Fri, 4 Sep 2026 14:41:25 +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=1788532886; cv=none; b=H5s/l4uc3TmT8fdZstEdHORV6rITMYUg4nFV1OghjLq9UN98xc0B+2GWk7Uo9Ou/5PoqeaVBn9nJZ1y+zPShZOrHBLNzEnpBCmrMhp2UNUj5Q/0jjADSny/8qzIp5FN7TfwgwEc5faPWYDpa1kwJIVxih+sBJit5Hxd/5Yz9EJg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788532886; c=relaxed/simple; bh=dPV7YYt+9jSQY38aHLmVpglkuVPvThHmR47SxszOGVs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=X5c6IGZEey5WyfSybG9vxzHIHIKa0VKRdYTHa1cUv0uegU1X+sVCbZYdvPEpuBKOsdR1fu+H/CzFuZPq9dMXBbocbh4wRbL4Vfx4d129qcFMPkVFkF8QRC1rkUkTahZwdv7dhepw7pwIkQODmrYOHXONfnPVIqBuzgGAS8pfvRM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RKtMykr1; 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="RKtMykr1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 712EB1F00A3D; Fri, 4 Sep 2026 14:41:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788532885; bh=83cGxc94L3/rpSSg6+7m8eJvyO9rx1qyIG+MvsR+ZdI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=RKtMykr1ia1/vDczsT8nHKSKIThvTVBHGp1UUgwLvCOIwQDoBDRBoSDXal2BrvcVF 0xoAyuHPAQi3ttOuo1any5ApfymplUrbA8RCg9kAUPBx3oJQonwxbD3kXVLn2xl3dJ ysfQ0tD8zeKHy3qqN9JDaGy85yBbjYqQwFOnYHONtxVTLpKJRP8SXCh3PhSrpUI3Mt yyfH3wrdU6+6TGrd0+lxxQ61f3AtOgk57z//UYGQ18fXa8tl5lhutg3wm9rZLpugxL mdKSXeehiM0CtdKXfjBIgWBzMV625vNzRhWIWHv9nwFOQ5OhxTnpu5IWbpUFuZu3Ef 2xa1BdaUSFjpg== 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 , Stephane Eranian Subject: [PATCH 4/5] perf jitdump: Write sample id fields in the order used by evsel__id_hdr_size() Date: Fri, 4 Sep 2026 11:40:56 -0300 Message-ID: <20260904144058.3341-5-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260904144058.3341-1-acme@kernel.org> References: <20260904144058.3341-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 jit_repipe_code_load() and jit_repipe_code_move() cast the sample id area appended to the synthesized mmap2 record to a fixed: struct { u32 pid, tid; u64 time; }; and store the timestamp at offset 8 whenever PERF_SAMPLE_TIME is set. That matches what evsel__id_hdr_size() accounts for only when PERF_SAMPLE_TID is set as well: the fields are appended in a fixed order, skipping the ones not requested by sample_type, so with PERF_SAMPLE_TID unset PERF_SAMPLE_TIME starts at offset 0 and idr_size is 8. Storing the timestamp at offset 8 then lands 8 bytes past the end of the id area, which for an event allocated as sizeof(*event) + idr_size is past the end of the heap allocation, besides corrupting the record the tooling reading it back expects. Walk the id area in the order used by evsel__id_hdr_size(), advancing past each field only when its sample_type bit is set, and keep the computed timestamp in a local variable instead of reading it back from the event buffer. Reported-by: sashiko-bot Cc: Stephane Eranian Assisted-by: LLM Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/jitdump.c | 64 +++++++++++++++++++++++++++------------ 1 file changed, 44 insertions(+), 20 deletions(-) diff --git a/tools/perf/util/jitdump.c b/tools/perf/util/jitdump.c index efb40d93e33ae664..f8b937a95fe84573 100644 --- a/tools/perf/util/jitdump.c +++ b/tools/perf/util/jitdump.c @@ -472,10 +472,8 @@ static int jit_repipe_code_load(struct jit_buf_desc *j= d, union jr_entry *jr) int ret, csize; uint64_t usize; pid_t nspid, pid, tid; - struct { - u32 pid, tid; - u64 time; - } *id; + uint64_t timestamp =3D 0; + unsigned long id; =20 nspid =3D jr->load.pid; pid =3D jr_entry_pid(jd, jr); @@ -561,13 +559,27 @@ static int jit_repipe_code_load(struct jit_buf_desc *= jd, union jr_entry *jr) event->mmap2.flags =3D MAP_SHARED; event->mmap2.ino_generation =3D 1; =20 - id =3D (void *)((unsigned long)event + event->mmap.header.size - idr_size= ); + /* + * The sample id fields are appended in the order accounted for by + * evsel__id_hdr_size(), skipping the ones not requested in + * sample_type, so they cannot be written through a fixed struct: + * with PERF_SAMPLE_TID unset, PERF_SAMPLE_TIME starts at offset 0 + * and idr_size is 8, so storing it at offset 8 runs past the end of + * the event allocation. + */ + id =3D (unsigned long)event + event->mmap.header.size - idr_size; if (jd->sample_type & PERF_SAMPLE_TID) { - id->pid =3D pid; - id->tid =3D tid; + struct { u32 pid, tid; } *id_tid =3D (void *)id; + + id_tid->pid =3D pid; + id_tid->tid =3D tid; + id +=3D sizeof(u64); + } + if (jd->sample_type & PERF_SAMPLE_TIME) { + timestamp =3D convert_timestamp(jd, jr->load.p.timestamp); + *(u64 *)id =3D timestamp; + id +=3D sizeof(u64); } - if (jd->sample_type & PERF_SAMPLE_TIME) - id->time =3D convert_timestamp(jd, jr->load.p.timestamp); =20 /* * create pseudo sample to induce dso hit increment @@ -577,7 +589,7 @@ static int jit_repipe_code_load(struct jit_buf_desc *jd= , union jr_entry *jr) sample.cpumode =3D PERF_RECORD_MISC_USER; sample.pid =3D pid; sample.tid =3D tid; - sample.time =3D id->time; + sample.time =3D timestamp; sample.ip =3D addr; =20 ret =3D perf_event__process_mmap2(tool, event, &sample, jd->machine); @@ -624,10 +636,8 @@ static int jit_repipe_code_move(struct jit_buf_desc *j= d, union jr_entry *jr) u16 idr_size; int ret; pid_t nspid, pid, tid; - struct { - u32 pid, tid; - u64 time; - } *id; + uint64_t timestamp =3D 0; + unsigned long id; =20 nspid =3D jr->load.pid; pid =3D jr_entry_pid(jd, jr); @@ -675,13 +685,27 @@ static int jit_repipe_code_move(struct jit_buf_desc *= jd, union jr_entry *jr) event->mmap2.flags =3D MAP_SHARED; event->mmap2.ino_generation =3D 1; =20 - id =3D (void *)((unsigned long)event + event->mmap.header.size - idr_size= ); + /* + * The sample id fields are appended in the order accounted for by + * evsel__id_hdr_size(), skipping the ones not requested in + * sample_type, so they cannot be written through a fixed struct: + * with PERF_SAMPLE_TID unset, PERF_SAMPLE_TIME starts at offset 0 + * and idr_size is 8, so storing it at offset 8 runs past the end of + * the event allocation. + */ + id =3D (unsigned long)event + event->mmap.header.size - idr_size; if (jd->sample_type & PERF_SAMPLE_TID) { - id->pid =3D pid; - id->tid =3D tid; + struct { u32 pid, tid; } *id_tid =3D (void *)id; + + id_tid->pid =3D pid; + id_tid->tid =3D tid; + id +=3D sizeof(u64); + } + if (jd->sample_type & PERF_SAMPLE_TIME) { + timestamp =3D convert_timestamp(jd, jr->load.p.timestamp); + *(u64 *)id =3D timestamp; + id +=3D sizeof(u64); } - if (jd->sample_type & PERF_SAMPLE_TIME) - id->time =3D convert_timestamp(jd, jr->load.p.timestamp); =20 /* * create pseudo sample to induce dso hit increment @@ -691,7 +715,7 @@ static int jit_repipe_code_move(struct jit_buf_desc *jd= , union jr_entry *jr) sample.cpumode =3D PERF_RECORD_MISC_USER; sample.pid =3D pid; sample.tid =3D tid; - sample.time =3D id->time; + sample.time =3D timestamp; sample.ip =3D jr->move.new_code_addr; =20 ret =3D perf_event__process_mmap2(tool, event, &sample, jd->machine); --=20 2.55.0 From nobody Sat Sep 26 04:29:48 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 61F6D4AE12F; Fri, 4 Sep 2026 14:41:29 +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=1788532890; cv=none; b=WjvyOGFUA79DKstQqQX3H7A2G6lBdH1FHXDVWVC81uMyaNKu/AvaqM0PCccaGgagI1gYGL7nuouXfna+SlHs9mJJ5PsQ0Rnx/xNAQmhKhEDIaV9Rcgu1cvUL7Fzn2rDfjfOjxRfvxVV4nQCw9HfrtklEq/vr6LLM632qwsogpD4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788532890; c=relaxed/simple; bh=0OFX+kU+M74+gQHFuQ54KprjKZmepHcrpnuizWKwuF4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=P7TJSTqQpL8pjLsAgQw3y4eshLFPD5I1AClz5Vo2cHn3xzPF86c2y4FNOvcTX7WTQ5L92EwJMDzBriB6lmO1RsxrpjijynQWzYr1ag4+vg/1tWu250b+w1QMyYJn68+mkUt8GO8xD3xwGr+4JZRSsXVR9AAhzAfMzkDbHSwosXo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OovZey8R; 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="OovZey8R" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 941431F00ACF; Fri, 4 Sep 2026 14:41:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788532889; bh=G5XXIVsnnMnL87uEXb7dOvLIfX/ZYGTR5Ky0opjA36I=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=OovZey8Rs3ade4fcOYYjtd+cbFN3b4Hsqe8UjRuqcGVhCASQQ6vfWRkuxbHJnSeyQ iiQy1jvXGXJEzm2j4kX1adCDoLyhA4afkmG+G00CB4Q2+zJKToa53hv3zTWsKvqq9q azC3PxhuSWcwg98xYKN9N90aUBBCVLcwTg75Rl8G5vXrqab5m/q5xL/UPAi3YJUW23 pdoVMOtHEZRD60t54ahgGZsAZIkTFJUsP5zAMW9DZze8PPUhhQj8ykjjlklI0dIjQ/ wAmPGmolvnvEjDh1M1GFvLwLaXSSKCA5TCj3Xr3ZItwewZNqQ7t3kR0jEYn5Z5ZUB+ q7Cu3TnnpTExw== 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 , Stephane Eranian Subject: [PATCH 5/5] perf jitdump: Size code_move event allocation with idr_size Date: Fri, 4 Sep 2026 11:40:57 -0300 Message-ID: <20260904144058.3341-6-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260904144058.3341-1-acme@kernel.org> References: <20260904144058.3341-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 jit_repipe_code_move() allocated the mmap2 event with a hardcoded +16, but computes event->mmap2.header.size as sizeof(event->mmap2) minus unused filename bytes plus idr_size. When idr_size is larger than 16, header.size exceeds the allocation, so perf_data__write() reads past the heap allocation, leaking adjacent heap memory into the generated perf.data file. Size the allocation with idr_size like jit_repipe_code_load() does. Reported-by: sashiko-bot Cc: Stephane Eranian Assisted-by: LLM Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/jitdump.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/perf/util/jitdump.c b/tools/perf/util/jitdump.c index f8b937a95fe84573..45a05316b3ca65b7 100644 --- a/tools/perf/util/jitdump.c +++ b/tools/perf/util/jitdump.c @@ -646,9 +646,10 @@ static int jit_repipe_code_move(struct jit_buf_desc *j= d, union jr_entry *jr) idr_size =3D jd->machine->id_hdr_size; =20 /* - * +16 to account for sample_id_all (hack) + * Sample ID is written past the end of the mmap2 record; size + * the allocation to account for it instead of a hardcoded +16. */ - event =3D calloc(1, sizeof(*event) + 16); + event =3D calloc(1, sizeof(*event) + idr_size); if (!event) return -1; =20 --=20 2.55.0