From mboxrd@z Thu Jan 1 00:00:00 1970 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 1CF01233955; Thu, 6 Aug 2026 12:37: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=1786019828; cv=none; b=o0RSDjoRAPg3zQ47NoxBTy+K8r8k8UPw4obY3UiQL1wGLcFMAqwR1Nu0eTkOyiWc9LSD9v3wcn8T27JaoaSRiJ7Y7yJ+0EbGEHBmreL+c1fMBk3+x6UPBAQuLzxepKA8+8Zjnx8lZyroZXHHE+E2Xzpy44LsF1NoBSysvwX/8Ds= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786019828; c=relaxed/simple; bh=XsPXYUoTfryy3R2b7vz0UCgSVVqpijR0pZ48YPHUBAs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=RKyPtdAOkP2CRK7dbawhMGpNJYHX6EC5XL22+Pykkdu4IZ5pUk2MMTo/Md+ww6EgFHRbCwYkwZgx6HF5FKB/F1no+68+0sKl1IpKdu3qChMzys6z1xbKwM2+SW3dzeAlzq00j3jZldmBIne+5he4kSMqOoL6kDIN0R0qS6xPZE8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gQTeo54L; 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="gQTeo54L" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A3D881F00A3D; Thu, 6 Aug 2026 12:37:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786019825; bh=uG0bUCcCsV5Kuer6dfyDYUG1djfBK9KIj4YAd8oXHAA=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=gQTeo54LRma0cT+JkbVzWG0KEJciLqRBBC5xSU47J43fU8TmoNOzTPYC6n/aRiDoH Ap3Ab32/Hv+d/w0p0JREO1XHosRx170YMpTXY5jrmoopAHzeL7SpOWdOg/LGn4Kx4K SzzQb6ClJeWw/uSz2AJnOh1B6TTt2qGQBp2ecBcQFMi9kGABs4LWzAjDj6AX9WQZLA 08woG0Kyi/kzBqrs6Vhgv+KA4ctXom/Gi2dxfUoH2pzdSnUdgJY2uHJTZNuofdJokQ xG+xqSXZVHjbPsB40Cw4IE9aB8ekt1r/W6PxULMqfpJwhDQq71/aZyVt4EYQWwCR+j yaYrrXPwhzK8Q== 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 10/12] perf jitdump: Validate debug entries on native (non-swap) path Date: Thu, 6 Aug 2026 09:36:01 -0300 Message-ID: <20260806123604.271277-11-acme@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260806123604.271277-1-acme@kernel.org> References: <20260806123604.271277-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: 8bit From: Arnaldo Carvalho de Melo The bounds-checking and nr_entry clamping added for the byte-swap path only runs when jd->needs_bswap is true. On native-endian files, nr_entry passes through unvalidated to jit_repipe_debug_info(), which stores it as jd->nr_debug_entries. Downstream, jit_process_debug_info() in genelf_debug.c iterates nr_debug_entries times via debug_entry_next(), which calls strlen() on each entry's name field — a crafted nr_entry causes OOB reads and writes. Add bounds-checked iteration in jit_repipe_debug_info() that validates each debug_entry fits in the payload and its name is NUL-terminated before calling debug_entry_next(). Clamp nr_debug_entries to the count of valid entries. Fixes: 598b7c6919c7bbcc ("perf jit: add source line info support") Reported-by: sashiko-bot Cc: Stephane Eranian Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Ian Rogers Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/jitdump.c | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git a/tools/perf/util/jitdump.c b/tools/perf/util/jitdump.c index d3de307532d55065..5a3ea2681fb37105 100644 --- a/tools/perf/util/jitdump.c +++ b/tools/perf/util/jitdump.c @@ -694,8 +694,10 @@ static int jit_repipe_code_move(struct jit_buf_desc *jd, union jr_entry *jr) static int jit_repipe_debug_info(struct jit_buf_desc *jd, union jr_entry *jr) { - void *data; - size_t sz; + struct debug_entry *ent; + void *data, *end; + size_t sz, valid; + uint64_t i; if (!(jd && jr)) return -1; @@ -715,10 +717,25 @@ static int jit_repipe_debug_info(struct jit_buf_desc *jd, union jr_entry *jr) jd->debug_data = data; /* - * we must use nr_entry instead of size here because - * we cannot distinguish actual entry from padding otherwise + * Clamp nr_debug_entries to entries that actually fit in the + * payload. The byte-swap path already does this for cross-endian + * files; validate on the native path too, since downstream + * jit_process_debug_info() iterates via debug_entry_next() which + * calls strlen() on each entry's name field. */ - jd->nr_debug_entries = jr->info.nr_entry; + end = data + sz; + ent = data; + valid = 0; + for (i = 0; i < jr->info.nr_entry; i++) { + if ((void *)ent + sizeof(*ent) > end) + break; + /* name must be NUL-terminated within the payload */ + if (!memchr(ent->name, '\0', (char *)end - ent->name)) + break; + ent = debug_entry_next(ent); + valid++; + } + jd->nr_debug_entries = valid; return 0; } -- 2.55.0