From nobody Tue Sep 29 04:09:12 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 59C192ED154; Thu, 13 Aug 2026 00:49:42 +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=1786582183; cv=none; b=QBkpHDLBwNgY08/vrh9728v2AuAM5835xC7y8o6VtFvthcC56dKZfCVYf8g07PeJSvr7DQRtngAHPilzi/MTFov2aMg0e4U7mE3C4GaRS8zb7ylmXqZ8qN8njpkSvthyiu/hs55HAiJ/jBJTWRXySugd91pEfcxlmmiAiV8Q+3c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786582183; c=relaxed/simple; bh=KCitQXu1asSsUX1uGrqEEM4zSjpm/F9WtsXOWN624/c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=UrAPc0r9xrFdKmqTL09drcjFBL3lhGdO9a4hl3DpEn0ZKazhJZHNMbDfSFjK7yucAxFQWfMBKVfFY8PGhohrRxUaVQ+0ofujxCYM/IOQ+zfoiStg62gJnxDqpYsASSAtx7d+83QRPv2JNIzNJ2CL/9JVaQrLepQgNv0PfPAhukk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=D5Z6Tcv8; 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="D5Z6Tcv8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6AD1E1F00A3A; Thu, 13 Aug 2026 00:49:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786582181; bh=bJKMxMFwfRyoD41QPLnMNGozZrZBr+GuKgym/EPJZHQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=D5Z6Tcv8bycGzobt/XH4zmCEguikJE4qpc/IjJUrqai7G+iqNjox3MOc7fqnhbyXn xX775MnaCl5t4fei9VmmZJpMkdyc+59CUc7Sax5WmM/iSr0pT435M/mos1GfPonQTZ 6/ZVCm3M7RatN5kTN+of8fIkraPFscPOv55oB3gOvayhOQOhCF5dfrj9TKYDGQwbnL Is2BhWTCrg2sbMfHhK8Bu6WYJ/cO36qnHqap6UYrQF4sKHDr9ar77huDWLcjoNbhe5 p0fdZhKfPteFetg14MJjMhrGo9idDHsQggNQakuV5ojTxrBi4MS9iAWZvppCGxqPXL MEOK36wDMtUdw== 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: Wed, 12 Aug 2026 21:49:20 -0300 Message-ID: <20260813004927.16738-2-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260813004927.16738-1-acme@kernel.org> References: <20260813004927.16738-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 04:09:12 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 476B82F3632; Thu, 13 Aug 2026 00:49:46 +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=1786582187; cv=none; b=roGP6WhPLKd55ioxiR+ZSxnoU+1oInK+L0svqnPhZ3j296DsuMt1/oXSBaxLn4Z7C8MdpB4lSHB7ualbOCnY4eLWzhiB0/d7BhvWwHWGauGNoyikySGhnvFYkAxK354VKHrwwuWfW5HqHIsSxZyUGkDpPfBZfPH/3GbxUfvkRbM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786582187; c=relaxed/simple; bh=urUtVkjwefdOhPlZHnowKM5UrjCzAgEJuR69ITMu7Ws=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Vd+a8Lf+vpaDRtY0pajQJAhdovS/rU2PMKRV5MAJ+iTrEPBnmjtnt1a4vDiPh/RB3ujG6Uc01NU6sNIkvsiAhB1PWgI2HgtA6rTMgZr9zIe6BaoZ2SxCWuslNRY9lED0wvnWvsk/mNjxeEADS61SlA9pWgepE46SYs72E3CAllc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=i4SDcxl5; 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="i4SDcxl5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6AD7B1F000E9; Thu, 13 Aug 2026 00:49:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786582185; bh=tE+gD/DYiH9Bu2QyVuZtH7jbAU4uDC65mNnhgfDx+Sk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=i4SDcxl5fku3KmwHuVIwhHL2vdZNd0Cd1n+ncuJ5di8fZEFlnsAZDOXRQqgdxOXS3 4iajt0Eg9/n4uUp36bik7lJ6J6By7WY8kcTamlQqiAODn06VP9UmLvv3c6mtAokrb+ aUH8If/YcHejT1CETbAfMA+eUZu9qkgcxx7LHyJa8swY3ANGn2BgUfb8iSn0fdOo+2 04HVjYQgYaDW1k6KwIvWCABhLzK3K71m6j0C/Bt7Lgo4krFb0PHzbFR/GfTV9YgvPf KgoVV6lnZEPFxNRsiAYvvsvfZhsnw/ADgAf3lqt+RMpI3zTGlWcWG8wS16henJqujE JXwvmS7hYHvLg== 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: Wed, 12 Aug 2026 21:49:21 -0300 Message-ID: <20260813004927.16738-3-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260813004927.16738-1-acme@kernel.org> References: <20260813004927.16738-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 04:09:12 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 398C72459EA; Thu, 13 Aug 2026 00:49:49 +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=1786582191; cv=none; b=BKY5Z/h6VsLghv0TftG3KQ5f33VjGeLVBA/XwfiKdMYqugdQ0SvFUPZc0RmKt4Gtv/d1Qe5LtcWBEqfcSLfYKe1A5P/SkZIzE41RdsvmuQt0M8XENnR5JtUFuNAlKNGjwaVgpUhhQ+i5xAJoS/SVxtOCqRh0rI3vpUcBqIet+6k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786582191; c=relaxed/simple; bh=wXfrViw83ley/fLzMSqJOPxqnIvdFApGnDd4yaNCo64=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Ruz/Uq7hLPUFL9/yv1os+hA9+VkYY1vOsD+7aW1+KtzsBfticsrF3R3FqKJg3HVzkNHiodbwmJm637mnNmvpymelQyh3PKx4IHEJceJtYRe8E466pGeyEFCTAvjrHUkwqudqOumV1UC5o5NbKWIZZt2vRCl8dwUq3TKVMrR7dKg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EO/Zyuaj; 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="EO/Zyuaj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6D4D41F00A3D; Thu, 13 Aug 2026 00:49:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786582189; bh=WuVjmL8PoiiOSZzjOJbihk5uOtwMRudcM4sg2VDkp2g=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=EO/Zyuaj8lp4Si1QlK7pCLr4FsOc734/uk4/VcysRU0nZAk9kx1udL902Imzk+4Lp amAqneD/mH/0c7ubHhBB/AV3H5h8b+rIODn+k23tcRqlgpBU/7CBOdTx2kpAxq13zN QI5S2fFltMoMDyLNh3YwBI5FEy3xEgewAqAYb4bohdJsl7d0RGbnAhFxuQtXn3aVWq M4i41jksSJfFsSy7C71/FpmxjG2vXJ7lcR+vGY7poCPcSHg7AfKF8faCY8MNq6SgQz Eagrjx2iOQUuOCDhQiicKtqTWUXgW5NAo9tH0mkCyebHyBPoyVMwubKNzSJbaQnBDt kqpwre4ei0p0g== 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: Wed, 12 Aug 2026 21:49:22 -0300 Message-ID: <20260813004927.16738-4-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260813004927.16738-1-acme@kernel.org> References: <20260813004927.16738-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 | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c index 124193453675ca18..c7fb9e1d07f14f17 100644 --- a/tools/perf/util/dso.c +++ b/tools/perf/util/dso.c @@ -1029,7 +1029,9 @@ 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; + assert(ret < 0); goto out; } =20 @@ -1151,8 +1153,10 @@ 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; + assert(ret < 0); goto out; } =20 --=20 2.55.0 From nobody Tue Sep 29 04:09:12 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 4BBA92459EA; Thu, 13 Aug 2026 00:49: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=1786582195; cv=none; b=Ct+Tw2mwJ70Xn6EOcf81n/eLQKGQ2siFAaxn+50qYugYaqL7HlW1i4ivItqTdrbvWI2qk088X+gZToqM2mAaxunhd/3US6K9LGtTTlXYtUw21nkAg3H1xepdAFsR/T9bN/pE6PtQdzkVv3vi0kC6BIENnLG4qD48XmHLxyDoCn8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786582195; c=relaxed/simple; bh=CbpAgGSwC3uY68iyUA3csZcsDcj3e3fYt+cvIyNBt2M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=lCZP6Q3rzJmzQib4j3EeijGDEbuorgEit9nU4qekjoBZmNnoHe2kWgpRt2iLkk9/l2nTZwRG6yLGhpf2JyaldOxb7vehoPprEq+vuZG3vvOhwN3CE4P3ysDnkQMIhi5Dt4W7OL2oWEXNKHaax8bS9mAbNC1jbxPEyLa9Z6RzwxY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Vsly/dvk; 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="Vsly/dvk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 630431F000E9; Thu, 13 Aug 2026 00:49:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786582194; bh=sTWu+SZuU5ioPBnTOBgpMFPMQ4IcsowNmnLhZJbGVZk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Vsly/dvkByzC9vCBNYaXNL9s6O84a4hpv0sh3IzjDQobY/1wIflrDwLzjAixtqMgU Ax+RVzZY5pCFUAtxXPdo/JQbTmNxPk3VxfucmKhNfzCJURZOyyrJbZJc9rBKeN4QzA M+uq5rxHMxg7OYQsZhkixiTVVPJehrFHmByMLtYXS0eTjRdHwLu6qXGxTM/+9igJfk 5J0mpDXA0M2u689GhdG9bR2mnwK9kTRk+NQ4wgpVeArl3rJ4d9GhRYVUHf1xCD84Hc EjLnJfQs+Y1vpYvbYzb0sEJ5pDgUulq39iiPmxpPlIq11xo9uR30Ez3Bd33LTTU1kU x+2zIeO8HMedw== 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: Wed, 12 Aug 2026 21:49:23 -0300 Message-ID: <20260813004927.16738-5-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260813004927.16738-1-acme@kernel.org> References: <20260813004927.16738-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 c7fb9e1d07f14f17..03e7f89d5465c91f 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 04:09:12 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 797942EF66B; Thu, 13 Aug 2026 00:49: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=1786582199; cv=none; b=p7CTtdBhlqkZoxVPKGpgaHa/CCA97vOg4YFef7bJXjjCe6r1xfs1C6HXHal01ncUDPcVGJuRl9sNpnnppuMyIiW/HR5jV+9LNvISD1K3gvRVAKy/1lnH6YMtKdaMHyuZsBeBi5pWciVszIIVaOQSI66S+WDykcIgjUAT85ACdck= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786582199; c=relaxed/simple; bh=2syjdaMv/Mee/1dBFBKh2VMNcou5wTO1ZWd5IDPuKUA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mZnHhDUrIEYy3ulPA1UmZg0qlv/gAp8xL1JaRfEb1RlgmBUVLZeTtRyT/2fIIa2xrAxVb/s+o/0L4DPF6l6uZpgMwqpLj5M7UVXxk5OI7Fb4qLEFlRIZh8Rk6pqiHLwvDU85vWJpdVdTQMwRvdiIusVSiAwvHnTzPr7wxE4o8v4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lU2lbsrb; 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="lU2lbsrb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7EA611F00A3A; Thu, 13 Aug 2026 00:49:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786582198; bh=vE5YCx5Sc9WzuwGSZa37Dgb8gWMC+horNLeZfxc8lEQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=lU2lbsrbgcqRARpsIsmg3z7NPabnlQGjlkWlaKyC6ur/K7IqRyxxWyzGXlXxYG6FE lk5Iqs0M5blZBoDoInolKC66GG4EQqQ+vPmtjlWkaLXYEJWNC36LvnVn5sODWgEeEe 0TPmm7xaN+tYomxGf3F1kRBlL0L1VDJkyRKbMX8wKEGX5dfeH5D7Ws2/emZY7OdVwX NpPGzIddtMKioYrgC28Kb/zxfykOhaRB/5rrVTRw9w7BN2qN609om7a2Pj7TKsfmUQ /lgLtRoXWpdfaIvg4ZyOtm6MVIvIg9yHt0VypwqYMVViWIK7CLn8BbepsO3SemSxyl DVwBvcb5dV6Hw== 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: Wed, 12 Aug 2026 21:49:24 -0300 Message-ID: <20260813004927.16738-6-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260813004927.16738-1-acme@kernel.org> References: <20260813004927.16738-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 03e7f89d5465c91f..68cd90b5605f8c50 100644 --- a/tools/perf/util/dso.c +++ b/tools/perf/util/dso.c @@ -2033,7 +2033,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