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 C040A33555F; Mon, 31 Aug 2026 13:12:17 +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=1788181939; cv=none; b=l2ytN9IA8i1fB6/FcsGFAtJY6cQPUDN60bVSDUdz0Le9hKhg+h+xZ4/+wBgvox0kNDkPPDyzo1EqQKm+PMSk4nOZIHyCmqXTNp8jU3tQNnctusN6l7OI3RG+YYIm0zNVi1bBwq003dlgCDN9mZyrwB2qVqbBNvPwVig2z7sKppM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788181939; c=relaxed/simple; bh=llpKev1Dqpe/1whA3ARXQ6reef6QrsLI9C4i/S64uUs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nm9XzosA44BjAQc1lyyTRXWql8bf9OAi3VTqcs+iWVYwHxX2qB9m7skOWmxnLihGnUBtEcc+Qww9qAN4hSKuJPWUqZllBflto5+X69ftycqIbasyc1DPrcoiR1/t9q+X6OcK+AclmVQi5Odja03PTyMZXsziawvkPNNqR+nrxew= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=e386AWlG; 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="e386AWlG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9BEFE1F000E9; Mon, 31 Aug 2026 13:12:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788181937; bh=32gxnMYpqc7W+ADUc7K9SwH9dlBo/g3B6bHhsMGOTRg=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=e386AWlGFqlpFPVOrqkHItqTpYwoYd6loFs5Olw4ALTUUQIqklFLaoFSCy5O3p9ed /daFNZP2CQq2HOxiHROiNZEHfNV00ozfIJjtJXsUneaO9olpes4qnlNcxQkAokIYxx YQktZ7ZI0/WWVG/FTeAHEmuUquM9AtQj4hQybc2qBFLTuIxEVu8W+WNudo1THRb0qH Hxei6wqD0fOa6unfZ5gZcQrN5dDk1dEMVkwKot0Sv2oRBeza8W7wyZg2zQSkydpUVk jbU03zaeIDo9Zxx1X/ejO/rCa2/tdOCaigdPuiPpUZO6qc66Ga+VYORhYfDBvlmLv3 4eUyHfW3N4tJw== 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 , Stefano Sanfilippo , Stephane Eranian Subject: [PATCH 12/12] perf jitdump: Validate unwinding sizes against record payload Date: Mon, 31 Aug 2026 10:11:08 -0300 Message-ID: <20260831131110.4681-13-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260831131110.4681-1-acme@kernel.org> References: <20260831131110.4681-1-acme@kernel.org> Precedence: bulk X-Mailing-List: linux-perf-users@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 jit_repipe_unwinding_info() copies unwinding_size and eh_frame_hdr_size from the jitdump record into jd-> fields without checking them against the actual payload size. Downstream, jit_add_eh_frame_info() in genelf.c computes unwinding_table_size = unwinding_size - eh_frame_hdr_size, which underflows when eh_frame_hdr_size > unwinding_size. The result is passed as d->d_size to libelf, causing an OOB heap read into the output ELF file. Validate that unwinding_size fits within the record payload and that eh_frame_hdr_size does not exceed unwinding_size before allocating or storing the values, so a bogus record cannot force a large allocation that is then discarded. mapped_size is likewise taken from the record and was narrowed into an int for the mmap2 len computation in jit_repipe_code_load() and jit_repipe_code_move(); values above INT_MAX would turn negative, producing a wrong mmap2 length. Use uint64_t for usize so the value cannot truncate. Fixes: 0284fecd13b6db3e ("perf jit: Add unwinding support") Reported-by: sashiko-bot Reviewed-by: Ian Rogers Cc: Stefano Sanfilippo Cc: Stephane Eranian Assisted-by: LLM Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/jitdump.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/tools/perf/util/jitdump.c b/tools/perf/util/jitdump.c index 5898a7d8eb962daf..d25a9fe9b020ce87 100644 --- a/tools/perf/util/jitdump.c +++ b/tools/perf/util/jitdump.c @@ -462,7 +462,8 @@ static int jit_repipe_code_load(struct jit_buf_desc *jd, union jr_entry *jr) u16 idr_size; const char *sym; uint64_t count; - int ret, csize, usize; + int ret, csize; + uint64_t usize; pid_t nspid, pid, tid; struct { u32 pid, tid; @@ -543,7 +544,7 @@ static int jit_repipe_code_load(struct jit_buf_desc *jd, union jr_entry *jr) event->mmap2.pgoff = GEN_ELF_TEXT_OFFSET; event->mmap2.start = addr; - event->mmap2.len = usize ? ALIGN_8(csize) + usize : csize; + event->mmap2.len = usize ? ALIGN_8((uint64_t)csize) + usize : (uint64_t)csize; event->mmap2.pid = pid; event->mmap2.tid = tid; event->mmap2.ino = st.st_ino; @@ -612,7 +613,7 @@ static int jit_repipe_code_move(struct jit_buf_desc *jd, union jr_entry *jr) char *filename; size_t size; struct stat st; - int usize; + uint64_t usize; u16 idr_size; int ret; pid_t nspid, pid, tid; @@ -761,6 +762,18 @@ jit_repipe_unwinding_info(struct jit_buf_desc *jd, union jr_entry *jr) return -1; unwinding_data_size = jr->prefix.total_size - sizeof(jr->unwinding); + + /* + * Validate sizes before allocating — jit_add_eh_frame_info() + * computes unwinding_size - eh_frame_hdr_size and uses the + * result as a buffer length for libelf. + */ + if (jr->unwinding.unwinding_size > unwinding_data_size || + jr->unwinding.eh_frame_hdr_size > jr->unwinding.unwinding_size) { + pr_warning("jitdump: invalid unwinding sizes in unwinding_info record\n"); + return -1; + } + unwinding_data = malloc(unwinding_data_size); if (!unwinding_data) return -1; -- 2.55.0