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 A831047277C; Wed, 5 Aug 2026 13:32:06 +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=1785936727; cv=none; b=r6VIRDlduGSR8cILR8a/TqtQ0qZW4EnPRZEWlPZCRyEGnw9blnhwgMPtlZSd5WUdBAAhCGMe1LOaPI+f+3N128XWsQX3V/nmTl7MaJsEMiVarH4NOYuhOd4cc4az5HNWH7oiKHkLgiZ+mNaWN81AQOmDmBeFq+QUZuioskE4aKY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785936727; c=relaxed/simple; bh=OppWOfMkaD8AmvoQxLEpbmpYg/DgP84tAUTmp045jQU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=RQNM8YGPynzymsfIhGoZD3Aai28f2ZMIJInothnRVfEd1nibj33xJTtrVRFLmQaFQWpz5JhnP/WEz4OXQFr2U9npZf92FR6BZsU8FL4egcpg6zGOtxgFScuYOTvfiZ9w/yFkcZia79muPavCcRRxiQ6eJ7WDIklcVzOw8vBty10= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=auFTQJvz; 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="auFTQJvz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E48B51F000E9; Wed, 5 Aug 2026 13:32:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785936726; bh=E613IRkQNGwdjNPYGRqbp3+jcaqY5Ab60reOU0zoRdc=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=auFTQJvz0/P285MIM3JW+xvcfliQBQfWHnpHQtra6ayn9Bn3VAQ12CrNIyf9LNL3u CMbfnUsNBqxsRgDyQZ3jlD2McRM2xl2O5/vpVibxRtU51Z8HmAE7wKbX3lCFF7e4cy O75kiTClyy14jlWBCUvmg2Yq6CuvlX/Zo32lm9pdImaRDPq01odGFdgBl4Kou2QBSQ Rn2TlJsuxJFTCDWZPFvGwhHlHQdHQ0C0rGprqVLdruoAzqUpGrhizb5GOy0R+Tw+9c yNo+nPxy5irsx6egU0iLuUrjIKnjsqVitOY6fHEOx3mevScDVcp9Wv4aZbNSiqXD7G pKXW3njbzBj6A== 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: Wed, 5 Aug 2026 10:30:09 -0300 Message-ID: <20260805133013.235016-11-acme@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260805133013.235016-1-acme@kernel.org> References: <20260805133013.235016-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 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 02840dbf8a1fc16c..87612ef3e232598e 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