From nobody Tue Sep 29 06:08:27 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 9FAE333556D; Tue, 11 Aug 2026 17:51: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=1786470715; cv=none; b=fpQGog7iuIzwzttn5OBVz7YRBdW2Qt9H3LNxWNTokchX2B09bKdLXDHr091aUlfcQYppp723Uwg1/i8hkxDzmHclshycbSTY8floCNfnPBkMECkWfoyAgb9kM76KVhsvkCpHWLhM39Y/+i/xEOlI1mCyLlhglJluAlQN2jGaB60= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786470715; c=relaxed/simple; bh=kzk5CkX8RdMqsObJo/KcrtAPYLjuJEBMsALxhLkWy2I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=O26W+Ohs0IkalzKYUGVTvCNNib/KHAj0eVR+G46Q5hfFMDkcV/COTJlD4lokyryOYLwjAJH3O/LbnWVSn18jHtgx1TzR3jYLzJSbHNtO+H0IIz8hNNKQg+N4ErlIfDA1KK4/Co3aABmMk3aACnV0gnohNyDZQO5DAVQ8X5CJ0Ao= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KWS4vQak; 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="KWS4vQak" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F3CFF1F00A3A; Tue, 11 Aug 2026 17:51:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786470714; bh=bAWbDiaqUHu4M/1lpQvabgGT2SgHwRAcAZ90fggnios=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=KWS4vQaktsmJrbZZ8JLm0VXNkfioAJUANJtMzIh6BB7Cb5egf7Ee+xlpzW8aNaJov ggM5GSGLA/OgF4cfhkYNMbSdetpzr+/7LWL+jSkmg6zGUHfG02hjHEj2IBMJE3Hm70 LGOOtPahYeHCkWK1MOCBcZoZVn/HgTmLfFIdMJh+jMdV6kkHxCtqCieAPSDRtySUNz mk6VMhTyG0qgpTaYf7fcLS4mo9BxrfPrQQLKqQyJK7WPnqvyfqKgjnzQs/IoHsEM7k 6pJwR+khDpZkvTVkm/C7yiFixwr1hfmfaO5dqw0SpcZqoHXFmcQhTfpDLYo2Os6JxL iXYe1UCevFvZw== 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 Subject: [PATCH 1/5] perf dso: Guard against errno==0 when dso__get_filename() returns NULL Date: Tue, 11 Aug 2026 14:51:30 -0300 Message-ID: <20260811175140.7235-2-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260811175140.7235-1-acme@kernel.org> References: <20260811175140.7235-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 __open_dso() computes fd =3D -errno when dso__get_filename() returns NULL. Some failure paths in dso__get_filename() (e.g. binary type mismatch) return NULL without making a syscall, leaving errno at 0 from a prior successful call. fd =3D -0 =3D 0, which is stdin =E2=80=94 subsequent code= treats it as a valid file descriptor. Fall back to ENOENT when errno is 0, ensuring fd is always negative on failure. Fixes: eba5102d2f0b ("perf tools: Add global list of opened dso objects") Reported-by: sashiko-bot Cc: Jiri Olsa Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers --- tools/perf/util/dso.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c index 2309196d8df3111c..fcd4b462992be6f2 100644 --- a/tools/perf/util/dso.c +++ b/tools/perf/util/dso.c @@ -640,10 +640,13 @@ static int __open_dso(struct dso *dso, struct machine= *machine) mutex_lock(dso__lock(dso)); =20 name =3D dso__get_filename(dso, machine ? machine->root_dir : "", &decomp= ); - if (name) + if (name) { fd =3D do_open(name); - else + } else { + if (errno =3D=3D 0) + errno =3D ENOENT; fd =3D -errno; + } =20 if (decomp) unlink(name); --=20 2.55.0 From nobody Tue Sep 29 06:08:27 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 6355733556D; Tue, 11 Aug 2026 17:51:58 +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=1786470719; cv=none; b=VroND3IdxKwopOtROfakquNAm7Qmvl8cRsCp3q1aKYOPRawLDByI0q2BMlCkOiIgvWsR094O44A5ll5mH27dAgxPuFeA09pDhW/tN+3PjdJGYZr8STM5z8Tio0NwuxGRj8IfJ72iiwplm5r+LfEfHW8JKs98ZuaxUQ9B2vfNlcI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786470719; c=relaxed/simple; bh=jAoDEexzBfmVbDUQRA+8xn8rzqgPgumPJ6dP0DvzSIk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=fUyuahwuHFxNBfIq5QA+GlRZyweyMRWYnZBCUCBGdY1NCsjMPOZXFoVaG3Zp0tHwKchNRBnMPSjTW8UWNde2FV+UbRJWNuzQeHjqSthjs54f3tepevOfYiFpEx02dNp1AFHx1Q8YgDfb46gPitNtiRdrE8V7adiQV6EPZfjfEI0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JAdtkkJb; 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="JAdtkkJb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DA4561F000E9; Tue, 11 Aug 2026 17:51:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786470718; bh=IbhEIOSm80yDQVumaY0vuMXvC7o2n8XYqsqqUww+NlE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=JAdtkkJbJLZfFqzRC13/4Alud2PARS0mIdWvihg+EYOcyogy6Dsn5c4687Juap/RM hCRddp7JqkXlH7fnzJhJkFyp7MRZttc/4OtJz3KFXnzPjF71SzTUKd7p9ShUabM5Pc csaKfJyoRYUBIJRg+ykr2pdM3MExxd7jSE+EsoAiUBPorhL+hGvx/ExxGXjFtvNuix gnBGmy2ISzCIZ2wcX45c416liXu43iFEFJYOSe80QZ+c2gz4D5A7VXMzBda6jW22uG xNtBS3eiIYp9AA6fGSpIVxPaNgBu/I+JDkY7CaxmtgaVsWaX0e4zFsCB4FrqH7UXWe mwhkBEYbXsOKg== 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 Subject: [PATCH 2/5] perf dso: Guard close() against invalid fd in dso__decompress_kmodule_path() Date: Tue, 11 Aug 2026 14:51:31 -0300 Message-ID: <20260811175140.7235-3-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260811175140.7235-1-acme@kernel.org> References: <20260811175140.7235-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 dso__decompress_kmodule_path() unconditionally calls close(fd) on the return value of decompress_kmodule(). When decompression fails or the DSO is not compressed, decompress_kmodule() returns -1. close(-1) fails with EBADF and clobbers errno, which callers up the chain (dso__get_filename =E2=86=92 __open_dso) depend on for error propagation. Guard the close() call with fd >=3D 0 so only valid file descriptors are closed. Fixes: 42b3fa670825 ("perf tools: Introduce dso__decompress_kmodule_{fd,pat= h}") Reported-by: sashiko-bot Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers --- tools/perf/util/dso.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c index fcd4b462992be6f2..124193453675ca18 100644 --- a/tools/perf/util/dso.c +++ b/tools/perf/util/dso.c @@ -395,7 +395,9 @@ int dso__decompress_kmodule_path(struct dso *dso, const= char *name, { int fd =3D decompress_kmodule(dso, name, pathname, len); =20 - close(fd); + /* decompress_kmodule() returns -1 on failure, don't close(-1) */ + if (fd >=3D 0) + close(fd); return fd >=3D 0 ? 0 : -1; } =20 --=20 2.55.0 From nobody Tue Sep 29 06:08:27 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 4463533556D; Tue, 11 Aug 2026 17:52:01 +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=1786470723; cv=none; b=cvv4rvkpvWlaJeyegmzs+DLZ0VF5gDRJyjXlUfuotpHwSQKsJNE+TgbfugpelT/hXw/TYybqBsmMivLovrD7KjiMIJns9Xtbamy3Gi4HJWN+OJ3Rig/0ta5jdB+lJ+VMvinjsWycifyjLJ37a7ZF1LjdussOGM63v56ZMJBWtlw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786470723; c=relaxed/simple; bh=513k8sIZ237IGTqrF3M0HFNOnoTZ/diJNj70c/sLgH0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NiD4AGwXRo18fAYiUTat1AGYj0YfUhnyCqSLJvFh+SsjF6e74y6wmrprCM8MALpo4vNY+z6IWbS3GMGSoPHJedA5r7IM3ejq1xYruHYXO+7tDn8r8b95fdSkckBUqr5pRtpDluRmNFgW2FFZ4elJ543l9sI9e48GnHzIHDf0Qy8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Tmq2xqse; 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="Tmq2xqse" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D8A71F00A3A; Tue, 11 Aug 2026 17:51:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786470721; bh=3aK21HaVMQJEhw+/RMJH82RbKAMYsMk3KdXl+tIUVxA=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Tmq2xqseoiAd6CVFGFvM7hLHZXOmhPqr9OQj9ZVqy+NKMCgnooCfnuAvFTjlYuh3R 7afauzNgkBSMMuCPQxggfcT4XqpgTGuWcPlDsfZr89av70Q3vJZppqHD48fv7EY9ub sNGmU6nA2WXe3trAMtM941oxqQ2Lm6QdNJJD7dWiiBFtfV4lTqYQPLpamAWosNjtcc XltRjtyQG0bG48it/jTLdW/vLz0IZ0cW3zjoon4P7D83qXbB2hBEEuzyP+JFTKiQP2 rGe4pAv3vK6/2QxjS90X8/yW9Hs5ZVAwM+Gf3CIDP3aAORIae+GMd8sGXHJih8pGV5 yx3kGBjFC806A== 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 Subject: [PATCH 3/5] perf dso: Use stored fd error instead of stale errno in file_read() and file_size() Date: Tue, 11 Aug 2026 14:51:32 -0300 Message-ID: <20260811175140.7235-4-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260811175140.7235-1-acme@kernel.org> References: <20260811175140.7235-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 file_read() and file_size() use ret =3D -errno when dso__data(dso)->fd is negative after try_to_open_dso() fails. By this point errno has been through mutex_lock(), nsinfo__mountns_enter(), and multiple open() attempts inside try_to_open_dso() =E2=80=94 it no longer reflects the actual open failure. If errno happens to be 0, ret =3D 0 looks like EOF rather than an error, and file_size() callers like dso__data_size() would then report a zero-sized file instead of failing. dso__data(dso)->fd is always negative on failure =E2=80=94 -errno from __open_dso() when no filename could be built (e.g. -EINVAL, -ENOENT), or -1 when do_open() itself failed =E2=80=94 and never 0, so use it directly instead of reading the stale global errno. Fixes: 33bdedcea2d7 ("perf tools: Protect dso cache fd with a mutex") Reported-by: sashiko-bot Cc: Namhyung Kim Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers --- tools/perf/util/dso.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c index 124193453675ca18..32ae5c78cdb906e6 100644 --- a/tools/perf/util/dso.c +++ b/tools/perf/util/dso.c @@ -1029,7 +1029,8 @@ static ssize_t file_read(struct dso *dso, struct mach= ine *machine, =20 if (dso__data(dso)->fd < 0) { dso__data(dso)->status =3D DSO_DATA_STATUS_ERROR; - ret =3D -errno; + /* fd is always negative here: -errno or -1, never 0 */ + ret =3D dso__data(dso)->fd; goto out; } =20 @@ -1151,8 +1152,9 @@ static int file_size(struct dso *dso, struct machine = *machine) try_to_open_dso(dso, machine); =20 if (dso__data(dso)->fd < 0) { - ret =3D -errno; dso__data(dso)->status =3D DSO_DATA_STATUS_ERROR; + /* fd is always negative here: -errno or -1, never 0 */ + ret =3D dso__data(dso)->fd; goto out; } =20 --=20 2.55.0 From nobody Tue Sep 29 06:08:27 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 1B74B345EB9; Tue, 11 Aug 2026 17:52: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=1786470727; cv=none; b=CJCfQcSaFv/6+NXGZGqG2P5NhXQUsw7/JpOULMFCzc3GhtRfnDlveX4JPQwplxFlxq88TMKgZ+W7o5aPtxuojFRqlOmjowKzrRT5EwPRD+sqjxYxJvqElUpWaPuDqKi7J9mOgWusrdFC1jYTuBPWFP3lVoDrUBSR6sPanjYJ18k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786470727; c=relaxed/simple; bh=SjsB4co41jSVoP6bnS8K970FIJHgbDqURpRb0nLHCus=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=BaKwihaS9QDGthNzK8X8sR3GvxGn/EmPSTVy8/a/2vj/IspCx7O50qgqYeQ3sUJeca/6gs9xdhYutSDYyL+VUDIo3mCG7+RRcjhny+x0aj4BVXxYV0anvfHT/Gzb7/tUrIdOITGKmtH9ElwzhXQNC7V8UswSCI47kpJjztI0F9w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eT/yQk6n; 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="eT/yQk6n" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D9221F000E9; Tue, 11 Aug 2026 17:52:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786470725; bh=NukpYtAtFanqUbiSgiuvXq4MtL6kmbQJhHG02AimIxQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=eT/yQk6na60lRZJnHPUk4nhR646E6jDyMcfFwUUEiF8QSlcoSKqeh8mlm7JzRFH9j L4m08Oud9PlYsY/YtGPuKgkCkfwys4CUeFSilp6L7XAIfymyr9/IYWRCkw/HqX703E h7ltnIdcsLLCxWqyO6PF4b7lLFlserdFQumelHjBF2/C/jYGmzksMpXw2yZnwsdVnK lN74MSTx3zVsIjXc+RzUEUWfEGWDd5lF58sdJYn3tyYKeVdeFT+qsdbTJg6v4wvHNR hgUp3vimU7M7ax8Jn847x1/7Ee92oIribuZ7EOS5J4KHCELvnJwBX+HTgjB0/IWI2m z4DX1rLwI9IYA== 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 Subject: [PATCH 4/5] perf dso: Guard against cache underflow on short reads in dso_cache__memcpy() Date: Tue, 11 Aug 2026 14:51:33 -0300 Message-ID: <20260811175140.7235-5-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260811175140.7235-1-acme@kernel.org> References: <20260811175140.7235-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 dso_cache__memcpy() computes cache_offset =3D offset - cache->offset, then cache_size =3D min(cache->size - cache_offset, size). The RB tree lookup in __dso_cache__find() matches using the full DSO__DATA_CACHE_SIZE window, but cache->size reflects the actual pread return value from dso_cache__populate(). A short pread (e.g. near end-of-file) makes cache->size smaller than DSO__DATA_CACHE_SIZE. If a subsequent access targets an offset past cache->offset + cache->size but within the DSO__DATA_CACHE_SIZE window, the cache entry is found but cache_offset exceeds cache->size. Since both are u64, the subtraction cache->size - cache_offset wraps to a large value, min() selects the caller's size, and memcpy reads out of bounds. Return 0 for an offset past the valid cached data. For a regular file a short pread only happens at end-of-file, so 0 is what a direct pread() at that offset would return: cached_io() stops its read loop as on EOF. Re-reading from the backing file would not help =E2=80=94 a second pread at the same offset returns the same short count. Fixes: 366df72657e0 ("perf dso: Refactor dso_cache__read()") Reported-by: sashiko-bot Cc: Adrian Hunter Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers --- tools/perf/util/dso.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c index 32ae5c78cdb906e6..8e16b919e80721f0 100644 --- a/tools/perf/util/dso.c +++ b/tools/perf/util/dso.c @@ -1005,7 +1005,20 @@ static ssize_t dso_cache__memcpy(struct dso_cache *c= ache, u64 offset, u8 *data, u64 size, bool out) { u64 cache_offset =3D offset - cache->offset; - u64 cache_size =3D min(cache->size - cache_offset, size); + u64 cache_size; + + /* + * The RB tree matches using DSO__DATA_CACHE_SIZE, but a short + * pread may leave cache->size smaller. For a regular file a + * short pread only happens at end-of-file, so an offset past + * the valid data is EOF: return 0, matching what a direct + * pread() at that offset would return, and cached_io() then + * stops its read loop. + */ + if (cache_offset >=3D cache->size) + return 0; + + cache_size =3D min(cache->size - cache_offset, size); =20 if (out) memcpy(data, cache->data + cache_offset, cache_size); --=20 2.55.0 From nobody Tue Sep 29 06:08:27 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 618FD34EF0C; Tue, 11 Aug 2026 17:52: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=1786470731; cv=none; b=UuG92dLV0Hrwbd4MhAWp3ZaZkrZiZpzc0a/u0gP1eUTaSQnLnldRV5QFtdhg+A9A2RbJVjUzV1PTVH5Tg3XQWFI2MpXwFQqr09RhpPKRoW3eM5bco9wAbFjqK7h6hrlcF4u1yBpl9tB2dTLQI5u8QtWSccckzPgRt7KfxhMFzWg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786470731; c=relaxed/simple; bh=wEj3U44ZkgGmUeTbAIvUHA4HkefQyR81vQVs9Ff5Wsc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qjj8cWXMF4OLMOH1Bcbh4fhZECacvpF1nJccgr9ZwiVJREvdxYBSbR7r9FR37lMWH7zi2MP45Oe/wzI++thdLBoDmMK45MU3VdcIwB5MRbTU1SLSVkagiTmEXFBqjx9Fz36D5uVU8G6Hp1sX+ODmHin920Y4cwzpZDcmJFTmVBI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=olzGZAoz; 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="olzGZAoz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59E9B1F00A3A; Tue, 11 Aug 2026 17:52:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786470730; bh=xgsj6giw+Z2i0aNaQTUB0L9TsWsLGJzJIS/7tZOy67E=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=olzGZAozPJ4es450+f4IZR4P0/eQGPMY5kVhDQa0+pX/enKY5SGCc+4O2wChHMDVZ wE++Rc0APqKcs5jcy3gFy+e874HhZfsJNaSqlC1rAjO/agHhAMIRDYI3H3Swrwirv8 Vyb98RxsUSGhspVJWRtldmHovVq8r8msfUKuHVpoKzJl5+3QYaknXw48Q5TEdrvLhY OoDM4qXgKsA3DfD9IZ5jyJBcV/DtcmfQlNI3TMceDLPsoFbl0xUAOgBs3jBgQbFj4U fextE9zMtR3mk6A1FNVm5TXS5p3yIib3+2qL1ZN0WIvOXAxB0yuHTIL0Tsp8uFaG1C 2oZNsfVUV9N0w== 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 Subject: [PATCH 5/5] perf dso: Replace assert with runtime check in dso__read_symbol() Date: Tue, 11 Aug 2026 14:51:34 -0300 Message-ID: <20260811175140.7235-6-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260811175140.7235-1-acme@kernel.org> References: <20260811175140.7235-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 dso__read_symbol() asserts that len <=3D jited_prog_len, where len comes from sym->end - sym->start (parsed from PERF_RECORD_KSYMBOL in perf.data). Both values originate from untrusted file input. With NDEBUG (production builds), the assert is compiled out, allowing an out-of-bounds heap read when the BPF program buffer is accessed. Without NDEBUG, a crafted perf.data crashes perf with an assertion failure. Replace the assert with a runtime bounds check that returns NULL with an appropriate error code, matching the existing error handling pattern in this function. Fixes: aa04707f507e ("perf dso: Support BPF programs in dso__read_symbol()") Reported-by: sashiko-bot Cc: Ian Rogers Cc: Song Liu Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers --- tools/perf/util/dso.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c index 8e16b919e80721f0..40b23b7cbb94049c 100644 --- a/tools/perf/util/dso.c +++ b/tools/perf/util/dso.c @@ -2031,7 +2031,12 @@ const u8 *dso__read_symbol(struct dso *dso, const ch= ar *symfs_filename, errno =3D SYMBOL_ANNOTATE_ERRNO__BPF_MISSING_BTF; return NULL; } - assert(len <=3D info_linear->info.jited_prog_len); + if (len > info_linear->info.jited_prog_len) { + pr_debug("BPF symbol length %zu exceeds jited_prog_len %u\n", + len, info_linear->info.jited_prog_len); + errno =3D SYMBOL_ANNOTATE_ERRNO__BPF_MISSING_BTF; + return NULL; + } *out_buf_len =3D len; return (const u8 *)(uintptr_t)(info_linear->info.jited_prog_insns); #else --=20 2.55.0