BPF List
 help / color / mirror / Atom feed
From: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
To: "Ihor Solodrai" <ihor.solodrai@linux.dev>,
	<sashiko-reviews@lists.linux.dev>
Cc: <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf v1 1/2] bpf: Fix tracing of kfuncs with implicit args
Date: Fri, 10 Jul 2026 19:23:17 +0200	[thread overview]
Message-ID: <DJV2D826YVRY.WSTQ4Z6CFX1I@gmail.com> (raw)
In-Reply-To: <ce047740-79fe-4fc5-a118-40252b169be8@linux.dev>

On Fri Jul 10, 2026 at 7:08 PM CEST, Ihor Solodrai wrote:
> On 7/9/26 6:21 PM, sashiko-bot@kernel.org wrote:
>> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>> - [High] Accessing `btf->kfunc_set_tab` without holding a module reference causes a use-after-free vulnerability.
>> --
>>
>> --- Patch [1]: [PATCH bpf v1 1/2] bpf: Fix tracing of kfuncs with implicit args ---
>> commit 13df91bf669b3a55c459c1663fbf726f9f52bc5c
>> Author: Ihor Solodrai <ihor.solodrai@linux.dev>
>>
>> bpf: Fix tracing of kfuncs with implicit args
>>
>> A kfunc marked with KF_IMPLICIT_ARGS flag takes implicit arguments
>> (such as bpf_prog_aux) that the verifier injects at load time.
>> resolve_btfids strips those from the kfunc's BTF-visible prototype and
>> keeps the real kernel ABI in a counterpart _impl prototype.
>>
>> Link: https://github.com/sched-ext/scx/issues/3687#issuecomment-4906694106
>>
>>> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
>>> index 64572f85edc83..20aeca6b4f95c 100644
>>> --- a/kernel/bpf/btf.c
>>> +++ b/kernel/bpf/btf.c
>> [ ... ]
>>> @@ -9114,6 +9114,26 @@ u32 *btf_kfunc_flags(const struct btf *btf, u32 kfunc_btf_id, const struct bpf_p
>>>  	return btf_kfunc_id_set_contains(btf, hook, kfunc_btf_id);
>>>  }
>>>
>>> +/*
>>> + * Return the union of a kfunc's flags across all hooks.
>>> + * Unlike btf_kfunc_flags(), not restricted to a calling
>>> + * program's hook. Used when attaching to a kfunc for tracing.
>>> + */
>>> +u32 btf_kfunc_accumulated_flags(const struct btf *btf, u32 kfunc_btf_id)
>>> +{
>>> +	enum btf_kfunc_hook hook;
>>> +	u32 *hook_flags;
>>> +	u32 flags = 0;
>>> +
>>> +	for (hook = 0; hook < BTF_KFUNC_HOOK_MAX; hook++) {
>>> +		hook_flags = btf_kfunc_id_set_contains(btf, hook, kfunc_btf_id);
>>> +		if (hook_flags)
>>> +			flags |= *hook_flags;
>>> +	}
>>> +
>>> +	return flags;
>>> +}
>>> +
>>>  u32 *btf_kfunc_is_modify_return(const struct btf *btf, u32 kfunc_btf_id,
>>>  				const struct bpf_prog *prog)
>>>  {
>>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>>> index 6515d4d3c0032..fde11a2f6869a 100644
>>> --- a/kernel/bpf/verifier.c
>>> +++ b/kernel/bpf/verifier.c
>> [ ... ]
>>> @@ -19121,8 +19146,8 @@ int bpf_check_attach_target(struct bpf_verifier_log *log,
>>>  		if (prog_extension &&
>>>  		    btf_check_type_match(log, prog, btf, t))
>>>  			return -EINVAL;
>>> -		t = btf_type_by_id(btf, t->type);
>>> -		if (!btf_type_is_func_proto(t))
>>> +		t = btf_attach_func_proto(log, btf, btf_id);
>>> +		if (!t || !btf_type_is_func_proto(t))
>>>  			return -EINVAL;
>>

Also, why not do it for BPF_TRACE_ITER case as well? I just feel keeping it
consistent may outweigh figuring out whether it's necessary in that case or not,
etc.

Please supply a cover letter in the next version too since you're sending
multiple patches.

Thanks

  reply	other threads:[~2026-07-10 17:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-10  0:59 [PATCH bpf v1 1/2] bpf: Fix tracing of kfuncs with implicit args Ihor Solodrai
2026-07-10  0:59 ` [PATCH bpf v1 2/2] selftests/bpf: Cover tracing implicit kfunc args Ihor Solodrai
2026-07-10  1:21 ` [PATCH bpf v1 1/2] bpf: Fix tracing of kfuncs with implicit args sashiko-bot
2026-07-10 17:08   ` Ihor Solodrai
2026-07-10 17:23     ` Kumar Kartikeya Dwivedi [this message]
2026-07-10 17:34       ` Ihor Solodrai
2026-07-10 17:40         ` Kumar Kartikeya Dwivedi
2026-07-10 19:34           ` 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=DJV2D826YVRY.WSTQ4Z6CFX1I@gmail.com \
    --to=memxor@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=ihor.solodrai@linux.dev \
    --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