From nobody Fri Oct 2 10:07:35 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 5358523C516; Sun, 2 Aug 2026 14:20:33 +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=1785680434; cv=none; b=kUUnoHnzw1Zp90868lR0akjg2hZCv6Ar9pS4szCx1xUOx9aMPc8zoU33TnnoCIlmNbgjpEM4CdfSu7SYeNwcD729cP1bXmhuuM+o+K5evIGB2Z6Kp5yjtlIkg16Btp/w9WPe/4exCY3u210f0oT/ch/EwS76n/5BiSGoMSrG0+4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785680434; c=relaxed/simple; bh=aU6z7QwckH6bvQO/v+gH/GmpjkrwmXuKodsDmnhGVx0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=LD96d/T86RMN6SWdJMAelH+jSRVew53i651qubvR3Coc3pYHdqByAbzqdI4Sx1iuXHmXa12GA1A2vy18LWWtJngxDDWdAEN8mH+0l48q6qVmJr1v3Tgzf5yB9+s4hwl0ntC58CfvfzS5NG/AWcQ3iEkQ2ClRjKRv9l3GGxB7WBA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hAtGdcuS; 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="hAtGdcuS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E77AD1F00A3A; Sun, 2 Aug 2026 14:20:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785680433; bh=MlJqZupASTk6ZYzHVpbWwsTkfNh0zHoNLoH1Cv5WpbY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=hAtGdcuSjvEMm0A37+ien0b0B3/VlSKDig2AIr8Ndi5yU4925RleAOiYgyQ6zs2xl ptYq3JgyLTg0BB7hus3c0lIBo2oLoBzelrD6mZ/6+7WjkdOiuGDbHnzfClg5H2jUBJ OuyRxPQ1Pm2ibGe7zK1v9OlB2RlrSxXgQmhHtFa/+gwtelZZt1I2PPkDdJdK8kedVv p+RjP9FZ2MNkKFQ7DFZ/t+bFOJ3Bz0PO1XStei8hdrSymSOq9QnpZlos0YS8xIM4DO R8JoKFBA4EUTo2L7tjlcsXEaUFrHjFO/zzlogsQBDak1ek1QQa+sRRFhTQr1sR/l0K +Y88Mz5JYoLAg== 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: Sun, 2 Aug 2026 11:20:18 -0300 Message-ID: <20260802142022.154219-2-acme@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260802142022.154219-1-acme@kernel.org> References: <20260802142022.154219-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 --- tools/perf/util/dso.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c index 2309196d8df3111c..e087a89066bdbc02 100644 --- a/tools/perf/util/dso.c +++ b/tools/perf/util/dso.c @@ -643,7 +643,7 @@ static int __open_dso(struct dso *dso, struct machine *= machine) if (name) fd =3D do_open(name); else - fd =3D -errno; + fd =3D errno ? -errno : -ENOENT; =20 if (decomp) unlink(name); --=20 2.55.0 From nobody Fri Oct 2 10:07:35 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 922C02931E9; Sun, 2 Aug 2026 14:20:36 +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=1785680437; cv=none; b=RjqipHA5gTu9AizaqXOICd6hoHfQlops6zpk9ACeBHnZh9hM82UgGS7vLuJ1N1Lmmj2Yq+p4ZSv2DI9kCmT6AYD/sPG2AJAGwlC5V5kIE9RfgEkR0Dn3TFSpc20nvFWEYEQvQ/Cn5sQ2m+jw6OZcPLdpAn4ZRWlK2+X7M281YFU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785680437; c=relaxed/simple; bh=n1QmrkenUqO3WkREjTlLTszPnas3fHNaLp3UhQYWC+E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=sDLKWRQCqSibpDgkJ7G2XE5MOE6XLMjeDTOh3WCeq1Nk4p6Yq0lS62WPyvtfZKRpkgKMZQze7ICQ9gFsbgo9PJpQ7Z4w7NtPvXDGACW/bM3sMGf6vx/ah0jK1tYbt47hYB3VucHwmW5peJKdYmapZAGAnWJXSIhCaCGBU3YVrzI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oPCVsQt2; 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="oPCVsQt2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 737701F000E9; Sun, 2 Aug 2026 14:20:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785680436; bh=CgtmxRD/mwQTFtenYmEuWnKNKZuIi1hpoSEM9ZDXMKo=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=oPCVsQt2Lp4SeDVQkc3A6FuKryV0KGVSzRguKvUn/ia30DWV4pnNXmw+QYR1f6BbT 1Ct3HsFkAIvNGN/ZMgFatkaWArQ5Ogsr0NUWQC4BlIPVKYHjMXnc3rCbTVVpHN9c/J iwYJI9kynr0VFwLxyB2WGc6yHAKt4d/RqV8avjHkFIT+Q/BLlwrwHBHDKkq37mO4sN vjjv/HZgnH/9Xu8S8F8oisjy9fKBxPmpjkAyZaZsOncTfdxR7posLGW9A6NRi4ASDt 33T8bv6oFkxNanH6yrsPD60fhzVQT2rOpOHGhpNY9bXJQsSRw2ONGYR4VBGbWcd8SS 5zMXXOw2b0wJw== 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: Sun, 2 Aug 2026 11:20:19 -0300 Message-ID: <20260802142022.154219-3-acme@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260802142022.154219-1-acme@kernel.org> References: <20260802142022.154219-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 --- 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 e087a89066bdbc02..d9c008465f377e79 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 Fri Oct 2 10:07:35 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 41F59224B05; Sun, 2 Aug 2026 14:20:40 +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=1785680441; cv=none; b=f/nJZZPSaAS+f2LS/4ZtVJPMQIt/iV0Xp62KvQEEcvSaS5auLv3x+DhCfehX1PFT/D2+2d9zJa+0M8lyUUOnUZ7+dvLA5SjWNanEM1SNU+ekLfVk9gYv1eFgoP4zXAHTvpRcgwD/nIcITeI8RHUW6ORNUBDrjZQ+IAEqAgU/Ef0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785680441; c=relaxed/simple; bh=E38mqzmh1ULxtmnYx9Qc3i6+YDscehl26iNbPiYoEJk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=B/P5Q7Em6pN+AoDyVYhbl7g+dFESPTd8AsMkgmLQSk3Il9+UFES0pyqVobVzYuqm6Y9bCPhUAyB8zPwjxXFqSrr7ol9nA9yOK8o0skJZKuTxUt59ZyvHbJk5A41DcNlaOcGsA/zU1+MQ/5+oJlaywFb478qckoyHx8a9tN9dN9I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UjG0Q6Mn; 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="UjG0Q6Mn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F28671F00A3A; Sun, 2 Aug 2026 14:20:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785680440; bh=hFRCYB4+70KmPZstmIqVO54bQF/LilRXRcei29A8Vdo=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=UjG0Q6MnGud7sJsRQPmlYSm8X7dUsdjLAC1vysVfnI8PzmGMyQVodh9gvYEhHBfr9 /okK/9niuJf/86bOsjHkpikVLLoXtXcO8SZg8HwVeeuG+9tg7Pe7Uroxci7vgy2nix Q4fix7unO9Th+FTqXHoX8cdC2p26jtxHguqd2eE+t9jXzjvQpQQadqVfeQEnJGVauC T9UcZ1u+0hXBXNCjQW33Q5NmzuH5bvASkPvo7xcnrgCYhDMNn4k3zCsrgM/ORlgQSH zBjCPmgigT6/l+VXlC5NrDyBn7iy7Ef0nPHLf5kyzNHuO/mruMauyGp1oC95kJd9lk UVfAjCQD2PkWw== 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() Date: Sun, 2 Aug 2026 11:20:20 -0300 Message-ID: <20260802142022.154219-4-acme@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260802142022.154219-1-acme@kernel.org> References: <20260802142022.154219-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() uses 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. The fd field already carries the negated errno from __open_dso() (e.g. -EINVAL, -ENOENT), 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 --- tools/perf/util/dso.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c index d9c008465f377e79..207f8744aac97e8c 100644 --- a/tools/perf/util/dso.c +++ b/tools/perf/util/dso.c @@ -1026,7 +1026,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 already carries the negated errno from __open_dso() */ + ret =3D dso__data(dso)->fd; goto out; } =20 --=20 2.55.0 From nobody Fri Oct 2 10:07:35 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 9A676279DC9; Sun, 2 Aug 2026 14:20:43 +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=1785680444; cv=none; b=XhN77mdq0mv4Juwlwm0F185nJtPvbgT+FT5y4C7TG+wOe1an1lmKNJYsCavRXd6gAFdEvAojGPwNVTkrUDcn/gSDAXx9f/YUKrivkKTLQ4qTjD9kc/PzTX7QYHJyIJPMw2Ux5yaCGzvs5txqCcTYQZ5axhTuQOCGco+FMf8pK5o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785680444; c=relaxed/simple; bh=T0au0knACm02e7WFBuaok0htElCfFeiNuNr3FVuD0TI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lDu+DQ+lOwznuzKcx4d8IERnAS5L/i6BfuuJxbCfdVQmlYMf1uxokw42b50Mrji0kCJbfJHjVHV9jWvUOavgn57YgtZGmCe997iIGga12vj0fCvgW1P1aJig96hJBHzwmbuG5G0XkMo9E1/hDDadaRdpPtkIs54ncLPYNmW+sZc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LvWaNoiV; 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="LvWaNoiV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D6E71F000E9; Sun, 2 Aug 2026 14:20:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785680443; bh=ypSDwZYY52iXi+nT9gOxURQmfbVF+SQVe22zSOqD8og=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=LvWaNoiVXtKbclGPlZt3uG7ElMrOqTPwKiwByg4h7mjKv8nOPHmXATgSDkf8OXmS2 E9oeh4dZbKwNzTYf+PXJ75dWF/znyME5WGZZPhFP2/Ca0kTuRMEdYUg7EWS614Jx/i 2BM09q8eRN9AsM2B+Xmq/7LJqmv0rlpXkbNs+brDBE2FM0dYfg4w09WAMAgPXt/r3o MM5sxSfT3Eic5BEFgWS1C7WsgbTPLWS/GIDs5JhVqNc//8wSjlWx3RF4oF6qZBjzzo k9iA9CDkSP1NulMu50/MibezZ8WX7rzF3yf9kK86FAyLW5yM7ZhjYTviW9aPWPbbVR 3K5Jv08aVMJcQ== 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: Sun, 2 Aug 2026 11:20:21 -0300 Message-ID: <20260802142022.154219-5-acme@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260802142022.154219-1-acme@kernel.org> References: <20260802142022.154219-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_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 (cache miss) when cache_offset falls outside the valid cached range, so the caller re-reads from the backing file. 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 --- tools/perf/util/dso.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c index 207f8744aac97e8c..a0de56c93592a5dd 100644 --- a/tools/perf/util/dso.c +++ b/tools/perf/util/dso.c @@ -1002,7 +1002,17 @@ 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. Treat an offset past + * the valid data as a cache miss so the caller re-reads. + */ + 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 Fri Oct 2 10:07:35 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 99C0E279DC9; Sun, 2 Aug 2026 14:20:47 +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=1785680448; cv=none; b=hrgQIy2KcIvCUGxsZ+449VtBv9xUhw+BbcuCTFXd0dYlD3fgh4xNW9vpOz8/tL2pUp6feMMUN+C94g3W6n7wKEfnMprN9kr78/xXPx9waM+32eP0W1SQReeUN40Fidp3TJBJHFOMdjcSK5BWaFr9VNuzbMsZzKHf3Ucb8o1LoeU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785680448; c=relaxed/simple; bh=9ghGZvR+z4A6yyxvsNCDL1xvfZHOTNX4GVWCklmmVAU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HXM9sb9tjpdOIwDfgW7We+gYTDOLLntc/Oqo9vET5txxP6JtyFN9erPEJI+eFNvCEuETLP1GYqZO04WIBD+6XIHHz55HrD2NZsgc39dPqA95OmtIAW1qaMYV0UV96iL6hehsW2F7MGLw7XVzknaQBZ1K72ud4Zv3fpouU61bAiE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YN9ljNhI; 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="YN9ljNhI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 081F41F00A3A; Sun, 2 Aug 2026 14:20:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785680447; bh=QAtZHxi1/mlCckbhP0Sap6uW+3wYT8TzghRz+mnk+5c=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=YN9ljNhI4jBx/MTPuBfuaNTrsh+378gyD2kWcJgSSGsy/GfMxzJ7KqseZwK37O5iB hLO9f1ASL+Snr8ldBiJxwLtgyqLiQIL0gYSHeacrTBjyoXJyqMnMR/BlDaAbMktVm/ E5fpdexsWaBcESxmLUy7M7hxEw5FyebtqMAV4/WNXfWXGt/SkuwjgQP9jUzkXM6Cg8 I9W/xt1RVaTAKquy8IApEFpvYsx7RFMi9yUETRDcLa/EOUZquhTerLwD5spgnovUkc 7pFlfUdeEzn2JDtE988JcX5ix8uf+2wP5JpOB4kEf470XA8WJEhY1B+uCGJQuto7mX GlFOvkVpX0GSQ== 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: Sun, 2 Aug 2026 11:20:22 -0300 Message-ID: <20260802142022.154219-6-acme@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260802142022.154219-1-acme@kernel.org> References: <20260802142022.154219-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 --- 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 a0de56c93592a5dd..f3209f285db7675b 100644 --- a/tools/perf/util/dso.c +++ b/tools/perf/util/dso.c @@ -2024,7 +2024,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