From nobody Tue Sep 29 06:08:29 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 2F0574582D6; Tue, 11 Aug 2026 17:12:14 +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=1786468336; cv=none; b=Fg42dMx9S43ynoYeojlARIwk6qsrJE4+YZwnnEjynZgmr3tK6J0W5F+pl3jp2FkDv9/4dMIy96/toqOOenljC8+pVePTWV1J/hjrKAD6s0fJ7svc1s9rcwbEys2IZv6uEDYxqCthpcXNno6O8UXUTzxl/Vpe1Cmk9Fszf7gudKo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786468336; c=relaxed/simple; bh=kzk5CkX8RdMqsObJo/KcrtAPYLjuJEBMsALxhLkWy2I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ilXqXSJgwuv0Jomqb6p+ZcEeCw45jTa7Zqi5fvkLKNj7ijWFH8/kkVrRCP/wWCg1X/rYb81ARQyybuagJN2Hg4t47QxlwVwiMKB4mYsU3AR4UD3DmRLRUJOiP/p/F01tELo+JZfU6WtaBQrW2rpeRMf3ma3rzaQEFQwmTf0ZLDg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RRbR0NrA; 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="RRbR0NrA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A725D1F00A3A; Tue, 11 Aug 2026 17:12:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786468334; bh=bAWbDiaqUHu4M/1lpQvabgGT2SgHwRAcAZ90fggnios=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=RRbR0NrAPi7dYy44UMMGLPiQBNWkDfYU3a0HneENsA8xQXZ95vkFjQrt5cJerpw9F STofsH+eFiL7lhlBFaveimZ+QzukccrCOeS3JKqt9oJVy+9sii5qJxVps5rG+0DBY/ aN00ToJFF6cuuKHm3d7T0cqyUH860xbMl7QgNPgNrhpPMhb+x8x4J49muMXb3FXbIk /oXUXFYH2fswy8X2uc4tP4iRcJiEmkBN+N2gbwrZbghTfJWjPAoggKVdZQaKL52cxV qHwVP6R/7ST269AU7OLG0BtiT3h4Z9QUxFwVLM/SwEREKH5BF7XnbSGv9R+Ot9/BGf HogDw3d79Mj2w== 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:11:56 -0300 Message-ID: <20260811171200.30096-2-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260811171200.30096-1-acme@kernel.org> References: <20260811171200.30096-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 | 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:29 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 538804570E3; Tue, 11 Aug 2026 17:12:19 +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=1786468341; cv=none; b=IgQexCDWuqF5BqrPOOJIOLoJNpdvRwydG2MlWpSK1vv4Ar5QHMUHy/dvMJ8B5e8aZi7Ac70oe640EuX3+utEi0BErgyPPMOznE0MvvWW7BshZcBPBH4DcVkoRTB7G0xZKPY1BSbRup0RVbD67QBUWNFxuIOfTckeKRopE7W5iYw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786468341; c=relaxed/simple; bh=jAoDEexzBfmVbDUQRA+8xn8rzqgPgumPJ6dP0DvzSIk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=n2xfvFqFw5CcwpbixAvftVm2+ElP/WLfSrWEQU/vXTixIGu0GH1KB6niWMEb72gDiRYhfDPxK6ZEJmTv9cWZA71Ep3bbXgLnHeTz/WDGkwEujlSM0gWTvy2jk/qa6Cb6cyJ/U7M6oRmpYXdp1L9rJXzCBNVHLc24OXgeu3QX7TA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MX7/m1+Z; 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="MX7/m1+Z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 737E61F000E9; Tue, 11 Aug 2026 17:12:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786468338; bh=IbhEIOSm80yDQVumaY0vuMXvC7o2n8XYqsqqUww+NlE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=MX7/m1+ZuiR+MdNdVXth2uN6bESSNYEyj6uv9XtL2b3iqKyzj/3CaPLRn6pLZ6UxI dV4tixXUy9MCOjvOSBYvbeynYw7i+kwgUuGlWgNEXdxvLsMZ0G5v2NARkEcRAvs1V0 r3sBA0uE+U7j1xYyOdaxwwzrGnu0Y/r2DRgdpV/f9LqIrorvop4pPoQ6y+O+BQsbU2 ST82slRGi2tl8/YmfcbXGRYYlb675GY0yPdyeDb35Eo/VwsvN2lzNTsu1HvQhliduo j0PsczPX6CmhCK6W9ZmW1/DHj3miwOtM8RO/hqsYL+MeRyALfpLOa8cqriafCF6Kzc lUya0JiQkMfNA== 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:11:57 -0300 Message-ID: <20260811171200.30096-3-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260811171200.30096-1-acme@kernel.org> References: <20260811171200.30096-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 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:29 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 F2DF6456E17; Tue, 11 Aug 2026 17:12:22 +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=1786468344; cv=none; b=WgdJdeKXADvMNHObBVRjCLQ3QrXoKWZm4kcVq+8d0ZvXn8OkcX49aNDolICIKX8BTRTl/3oGPWbauWHxPwqC5bSKnXLVjBcA2LtXiVbPIrX0jRFvRhakEB3PSWieNRZUpgTcp7q0BU3hq4uxrhvVgPNDqB/73Fx1AC2XXqg70/A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786468344; c=relaxed/simple; bh=mZZC7s2C29BbJPGOfHLgVI5BZY4Pb9KhphfBeyw98ZE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Sv/AMWPYpyqFDiVaWjlqBcn5mBpYJs78tocyWVyZJPd2XlqN61LFVneqSa24IPjGYIUdq5knXtxiIsT1JvL4IBDEdZmENKgnYpqeJ7uE0ca/91fMCQTgGW8eqykix+wmyTML5BogmQuZJgAtT9g/mS5PutJAykgaWggWKD/XONw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dgvpeqsI; 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="dgvpeqsI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E9371F00A3A; Tue, 11 Aug 2026 17:12:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786468342; bh=ddvN6mzZQPpjb1j9jQPuMJz+025tgjfM+zZlsoNai0U=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=dgvpeqsIp42S9n7rMPgGI7wDetYDvq4HLF88M8clh9fm9+oOWGgfPxJhcnZwBjEs6 mkcu1LUX4kJl7PJIu/8q68CLginJPOWSpW6uSWJv2cp+4MpT9UdEKY7QLJBqzrKKhP 5xfeJQFGKgnNurkvqpw+yA4sQr168+Zcz/woyzZ5ILt5yjjrTS8DeA+48xRvNUdZ1u 0o8zGRkuR8Jk3jmh5hsVBwqu3eMQlJ1+NhTD1bo7looCip3sIBsSntff5DzXqIn3if cxDxhWbqe46Cpc3dnLUaxYr956QP8fVFCuxrA6q9F/YSvr0NEqh9GJd4a1BXj3AzRE 2J2XtW0FvZJZA== 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: Tue, 11 Aug 2026 14:11:58 -0300 Message-ID: <20260811171200.30096-4-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260811171200.30096-1-acme@kernel.org> References: <20260811171200.30096-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 124193453675ca18..845a384a4d56779b 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 already carries the negated errno from __open_dso() */ + ret =3D dso__data(dso)->fd; goto out; } =20 --=20 2.55.0 From nobody Tue Sep 29 06:08:29 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 DA193431A4C; Tue, 11 Aug 2026 17:12:26 +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=1786468348; cv=none; b=LNYFhkweozzkJIk1gkBuJ8XpzTiqTvv+4xUaoN+jRkxTjJY7sZNKXQwx1LnVjBgGTpsCVq46L16BJbX1M2qn01O6zd9oD59QKLuw9ErAkSHeJc38iQpJwuVP5WgSSYU1fY9GsWzY1veiEDHgUTcVakYyevPKEBzdx77OYHyhHos= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786468348; c=relaxed/simple; bh=nRAE/J1F4RjeaIp94T6DfvFbqHH9zBfwF3h8QR0oGfs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=N43fPPaZHkirh1Ec8tmj6efq+qwKtFpqk6LMb24LKecpoxASuJC5XOLWevkedIlmwiLAOnforGJiylaYQiCLfNwDWDMiF/uQV03qk50YPEyqUq+31ZJRMtvkSYdXCPkdg5NVgv4HOIZbD6SYbbV4NjwEnNb/KwySoOb/vENTut0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mluJTESM; 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="mluJTESM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 56D5D1F000E9; Tue, 11 Aug 2026 17:12:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786468346; bh=edC2gXtMicewaQ3Uim/RZ0IU6TrcKLdQqTeAwo9ObVE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=mluJTESMT0KIFk7TF4VwtVvbrTVXckNkxFdyjG+8PmntKbQM8EYBYXVcmP8tHuEea kRY0pMLSP+dfkinTvCRgdRa9FzyCzE15J+1XXXubCm4MiRihwwAW+D9z9NIRtlpHgV sxm/36MLvW0p2zmPC/AkAaZdukayE9Kzn7ET8Vp5hQspdXT9hVfoPpK9Ei2qIPkOi5 hTLs6ZvWtQ2oFmSAGvlVyuKkOyR3ptanjahkXxxzwkui3/jWaJBqWU3svMIo46MpUx PT5MkwhQ0fsD4cjCSc4mu0eC6COQRHFcKCZ6XcEbBi9Hb7DCcWdtN7rD5Vg/KxGb5l wzxGphUWO6hjA== 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:11:59 -0300 Message-ID: <20260811171200.30096-5-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260811171200.30096-1-acme@kernel.org> References: <20260811171200.30096-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 845a384a4d56779b..2cf9f44a87903d7d 100644 --- a/tools/perf/util/dso.c +++ b/tools/perf/util/dso.c @@ -1005,7 +1005,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 Tue Sep 29 06:08:29 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 737044582DD; Tue, 11 Aug 2026 17:12:30 +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=1786468351; cv=none; b=qDyKNJYFrfPYHGIopj0OThU3zM3x5PPDLFHDtkVt97L8/wcZ4iyK8YRuXNY3DnXpPB2Ic/ED5B2KjC7VIpDwWjw3UWFV9HfemEOFralCRXNIe89/1DQPtY0pWn6zDVb69zr29FYdBF95tKFDCEN/8HKrgsXsQ2hylEzfNqS0fcE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786468351; c=relaxed/simple; bh=a2sYeoCNrwrU3geY55t3idlAIEB9k0GzPOt11pWY4ZQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sWxblR/loKAzPwJWDp4hxVAWH+yuaubiXvoqQX2XwAEW6/L8yWXXvMlOYbgx0FWpUOyRvIhdXlBwH4Z0JrIIjXsJNHSqiWX/ynRD/WdKelM8JmfjCBKi9LiOOexqt2WABB56mBQy/WgF2OzcRRyu0lPO0osk2eSHacoVnTwECSg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=P8x+1p/G; 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="P8x+1p/G" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22FB41F00A3A; Tue, 11 Aug 2026 17:12:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786468350; bh=EV37sXYMvDxNyI3O2pN+AzI6ZNZUFdIY6F/NfIRVeVY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=P8x+1p/GqZY4t4eKgvYvwG9hDbRO9AJFk0V64X+kxur6GyEcTqYuQhDVK7NBQL413 DPSuXGVnJv/vMrC0HrNP+d8ANG+Gv1fM1FocQmStw069T+oR9GljeaLW2TzPkEh+EN qJJq7IxpId5fnBIT863T1B8At5sKteaTbsVt5SPCvWL6qNTbU1LSXNCSjBf8R+vI1G RqKDEWKoIy3k5L/FZm6YdlLTrpO71n3SCdcPwDqWq/jHfg9W8ujQkICyP8PjeDggwb ycA4cCa3ioN2K4Pw8em3pjuSVyOE4xaSif8KQiiQrsyOEbeSfY8Te7jdhOokSg56Q6 NksOe/QnXftGA== 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:12:00 -0300 Message-ID: <20260811171200.30096-6-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260811171200.30096-1-acme@kernel.org> References: <20260811171200.30096-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 2cf9f44a87903d7d..031de8f1da0329b2 100644 --- a/tools/perf/util/dso.c +++ b/tools/perf/util/dso.c @@ -2027,7 +2027,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