From: sashiko-bot@kernel.org
To: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 12/17] libbpf: Resolve pointers to functions in read-only data
Date: Thu, 24 Sep 2026 03:27:58 +0000 [thread overview]
Message-ID: <20260924032759.3CE1A1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260924031042.1690890-13-alexei.starovoitov@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] bpf: exception callbacks bypass callx and func ptr evaluation
--
commit 977905067f5778d4a89e59b4be93e1e229b29d4a
Author: Alexei Starovoitov <ast@kernel.org>
libbpf: Resolve pointers to functions in read-only data
This patch enables libbpf to resolve pointers to static functions located in
read-only data, such as struct ops or vtables. It creates per-program map copies
containing the proper offsets, which the kernel later replaces with addresses.
Programs utilizing callx automatically have statically referenced subprograms
appended during relocation.
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index cd1ea1bb53cbf..fc9b7540aca63 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
[ ... ]
> @@ -7046,7 +7301,7 @@ bpf_object__relocate_calls(struct bpf_object *obj, struct bpf_program *prog)
> if (err)
> return err;
>
> - return 0;
> + return bpf_object__append_func_ptrs(obj, prog);
> }
>
[Severity: Medium]
Will this miss callx instructions and function pointers used inside exception
callbacks?
Looking at bpf_object__relocate() in tools/lib/bpf/libbpf.c,
bpf_object__relocate_calls() is executed before exception callbacks are
appended:
tools/lib/bpf/libbpf.c:bpf_object__relocate() {
...
err = bpf_object__relocate_calls(obj, prog);
if (err) {
...
}
err = bpf_prog_assign_exc_cb(obj, prog);
if (err)
return err;
if (prog->exception_cb_idx >= 0) {
...
if (subprog->sub_insn_off == 0) {
err = bpf_object__append_subprog_code(obj, prog, subprog);
...
}
}
...
}
If the exception callback contains a callx instruction or references a function
pointer map, it seems they would bypass the bpf_object__append_func_ptrs()
evaluation. This could cause their read-only maps to be mis-relocated since
the has_callx state and subprogram appending are finalized prior to processing
the exception callback.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260924031042.1690890-1-alexei.starovoitov@gmail.com?part=12
next prev parent reply other threads:[~2026-09-24 3:27 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 3:10 [PATCH bpf-next v2 00/17] bpf: Indirect calls of bpf subprogs (callx) Alexei Starovoitov
2026-09-24 3:10 ` [PATCH bpf-next v2 01/17] bpf: Fix infinite loop in check_max_stack_depth() Alexei Starovoitov
2026-09-24 3:10 ` [PATCH bpf-next v2 02/17] selftests/bpf: Test recursion through a global function and a callback Alexei Starovoitov
2026-09-24 3:10 ` [PATCH bpf-next v2 03/17] bpf: Keep functions with address taken when removing dead code Alexei Starovoitov
2026-09-24 3:10 ` [PATCH bpf-next v2 04/17] bpf: Prepare static analysis passes for callx instruction Alexei Starovoitov
2026-09-24 3:56 ` bot+bpf-ci
2026-09-24 4:18 ` Eduard Zingerman
2026-09-24 3:10 ` [PATCH bpf-next v2 05/17] bpf: Add callx instruction to call bpf subprogs indirectly Alexei Starovoitov
2026-09-24 3:28 ` sashiko-bot
2026-09-24 3:10 ` [PATCH bpf-next v2 06/17] bpf: Add callx calls to the call graph Alexei Starovoitov
2026-09-24 3:26 ` sashiko-bot
2026-09-24 3:56 ` bot+bpf-ci
2026-09-24 5:00 ` Eduard Zingerman
2026-09-24 3:10 ` [PATCH bpf-next v2 07/17] bpf, x86: Add JIT support for callx Alexei Starovoitov
2026-09-24 5:33 ` Eduard Zingerman
2026-09-24 3:10 ` [PATCH bpf-next v2 08/17] bpf, arm64: " Alexei Starovoitov
2026-09-24 3:10 ` [PATCH bpf-next v2 09/17] bpf: Discover subprogs described by func_info Alexei Starovoitov
2026-09-24 5:42 ` Eduard Zingerman
2026-09-24 3:10 ` [PATCH bpf-next v2 10/17] bpf: Recognize pointers to functions in read-only maps Alexei Starovoitov
2026-09-24 3:10 ` [PATCH bpf-next v2 11/17] libbpf: Support pointers to static functions in data when linking Alexei Starovoitov
2026-09-24 3:10 ` [PATCH bpf-next v2 12/17] libbpf: Resolve pointers to functions in read-only data Alexei Starovoitov
2026-09-24 3:27 ` sashiko-bot [this message]
2026-09-24 3:10 ` [PATCH bpf-next v2 13/17] libbpf: Treat .data.rel.ro as " Alexei Starovoitov
2026-09-24 3:10 ` [PATCH bpf-next v2 14/17] libbpf: Support pointers to functions in read-only data in light skeleton Alexei Starovoitov
2026-09-24 3:10 ` [PATCH bpf-next v2 15/17] selftests/bpf: Add tests for callx Alexei Starovoitov
2026-09-24 3:56 ` bot+bpf-ci
2026-09-24 3:10 ` [PATCH bpf-next v2 16/17] selftests/bpf: Add tests for callx through pointers in read-only data Alexei Starovoitov
2026-09-24 3:10 ` [PATCH bpf-next v2 17/17] bpf, docs: Document callx instruction Alexei Starovoitov
2026-09-24 5:50 ` [PATCH bpf-next v2 00/17] bpf: Indirect calls of bpf subprogs (callx) patchwork-bot+netdevbpf
2026-09-24 5:55 ` Eduard Zingerman
2026-09-24 6:00 ` Alexei Starovoitov
2026-09-24 17:50 ` Ihor Solodrai
2026-09-24 18:09 ` Alexei Starovoitov
2026-09-28 23:13 ` Ihor Solodrai
2026-09-29 6:04 ` Alexei Starovoitov
2026-09-29 16:40 ` Ihor Solodrai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260924032759.3CE1A1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).