From: sashiko-bot@kernel.org
To: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 1/2] bpf: Verify global subprogs in each sleepability context
Date: Sat, 05 Sep 2026 05:32:06 +0000 [thread overview]
Message-ID: <20260905053206.87C6E1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260905051224.2325381-2-memxor@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Global subprograms can bypass caller lock and reference balancing by using bpf_tail_call(), leading to permanent resource leaks.
--
commit abbef478df8567a76eb64989bbf7f08c717afd13
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>
bpf: Verify global subprogs in each sleepability context
This commit updates global subprogram verification to independently verify
each context (sleepable and non-sleepable) that calls it. This prevents
non-sleepable callbacks from incorrectly treating the context as sleepable
and allowing RCU-protected pointer misuse.
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 5b51e7ee1a3f9..f759a020c8a5a 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -9988,11 +9989,10 @@ static int check_func_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
> if (env->log.level & BPF_LOG_LEVEL)
> verbose(env, "Func#%d ('%s') is global and assumed valid.\n",
> subprog, sub_name);
> + sub_aux->called[in_sleepable_context(env)] = true;
[Severity: High]
This is a pre-existing issue, but while reviewing the global subprogram
execution context changes here, I noticed a potential resource leak
related to tail calls.
When a global subprogram is verified independently with a fresh verifier
root in do_check_common():
kernel/bpf/verifier.c:do_check_common() {
...
state = kzalloc_obj(struct bpf_verifier_state, GFP_KERNEL_ACCOUNT);
...
}
The new state starts with zero locks and references. If the global
subprogram executes a bpf_tail_call(), check_resource_leak() inside the
subprogram's verification will succeed.
However, back in the caller's context in check_func_call(), the verifier
seems to evaluate the call assuming it will return normally:
kernel/bpf/verifier.c:check_func_call() {
if (bpf_subprog_is_global(env, subprog)) {
...
if (env->subprog_info[subprog].might_throw) {
branch = push_stack(...);
return process_bpf_exit_full(env, NULL, true);
}
/* continue with next insn after call */
return 0;
}
}
The caller check correctly handles divergence for might_throw, but
appears to silently ignore has_tail_call for global subprograms. If a
user program acquires a resource (e.g. bpf_rcu_read_lock) and then
calls a global subprogram that performs a tail call, does this bypass
the caller's resource cleanup and validations, permanently leaking the
resource?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260905051224.2325381-1-memxor@gmail.com?part=1
next prev parent reply other threads:[~2026-09-05 5:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-05 5:12 [PATCH bpf-next v2 0/2] Fix global subprog verification context Kumar Kartikeya Dwivedi
2026-09-05 5:12 ` [PATCH bpf-next v2 1/2] bpf: Verify global subprogs in each sleepability context Kumar Kartikeya Dwivedi
2026-09-05 5:32 ` sashiko-bot [this message]
2026-09-05 5:40 ` Kumar Kartikeya Dwivedi
2026-09-05 6:05 ` bot+bpf-ci
2026-09-05 6:13 ` Kumar Kartikeya Dwivedi
2026-09-05 22:39 ` Alexei Starovoitov
2026-09-11 19:12 ` Eduard Zingerman
2026-09-05 5:12 ` [PATCH bpf-next v2 2/2] selftests/bpf: Test global subprog callback contexts Kumar Kartikeya Dwivedi
2026-09-05 6:05 ` bot+bpf-ci
2026-09-11 20:20 ` Eduard Zingerman
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=20260905053206.87C6E1F00A3D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=memxor@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.